尧图网站建设 
在 Google GKE 上部署 QuickwitWorkload Identity 与 GCS 对象存储配置实战【免费下载链接】quickwitCloud-native OSS search engine for observability项目地址: https://gitcode.com/GitHub_Trending/qu/quickwit本指南以 Quickwit 官方 Kubernetes 部署文档为核心完整演示如何在 Google Kubernetes EngineGKE上通过 Helm 部署一个使用 Google Cloud StorageGCS作为索引与元数据存储的 Quickwit 集群。你将掌握 GCP Service Account 与 GKE Service Account 的绑定Workload Identity、正确的 IAM 权限授予、values.yaml配置编写以及部署后的验证与卸载流程并了解 Quickwit 底层如何解析gs://URI 与认证凭据。背景为什么在 GKE 上部署 Quickwit 需要专门配置Quickwit 是云原生的可观测性搜索引擎其核心设计是存储与计算分离索引数据splits与元数据统一存放在对象存储中节点自身不持久化索引。因此在 GKE 上部署 Quickwit 的第一步不是写 Deployment而是解决节点访问对象存储的权限问题。Quickwit 原生支持 Google Cloud StorageGCSAPI这一能力自 0.7 版本起提供更早版本需要使用 S3 互操作密钥。其底层通过 opendal 的 GCS service 与gs://协议对接源码位置见 google_cloud_storage.rs。从 storage_resolver.rs 可以看到StorageResolver::resolve会根据 URI 的协议Protocol::Google将gs://请求分发给GoogleCloudStorageFactory并在编译特性gcs未开启时返回明确的Quickwit was compiled without thegcsfeature错误——这意味着你使用的官方镜像已内置 GCS 支持无需额外编译。本指南采用 GKE 官方推荐的Workload Identity方案通过 GKE Service Account 与 GCP Service Account 的绑定让集群内的 Pod 自动获得访问 GCS 的短期凭据无需在配置中硬编码任何密钥。前置准备在开始之前请确认环境满足以下条件一个可用的 GKE 集群且已配置好kubectl上下文版本与集群相差不超过一个 minor 版本可用kubectl version校验Helm v3 已安装helm version校验gcloud命令行工具已安装并登录gcloud auth login目标 GCS Bucket 已创建本指南以your-bucket为例。第一步创建命名空间与 Service Account首先创建用于本次演练的命名空间本指南使用quickwit-tutorialexport NSquickwit-tutorial kubectl create ns ${NS}接下来需要两个 Service AccountGCP Service Accountquickwit-tutorialGCP 层面的身份拥有访问 GCS Bucket 的权限GKE Service Accountquickwit-saKubernetes 层面的身份供 Quickwit Pod 使用通过注解绑定到前者。创建 GKE Service Account 并注册 GCP Service Accountexport PROJECT_ID{your-project-id} export GCP_SERVICE_ACCOUNTquickwit-tutorial export GKE_SERVICE_ACCOUNTquickwit-sa export BUCKETyour-bucket kubectl create serviceaccount ${GKE_SERVICE_ACCOUNT} -n ${NS} gcloud iam service-accounts create ${GCP_SERVICE_ACCOUNT} --project${PROJECT_ID}第二步授予 GCS Bucket 权限为 GCP Service Account 授予目标 Bucket 的对象管理权限gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \ --member serviceAccount:${GCP_SERVICE_ACCOUNT}${PROJECT_ID}.iam.gserviceaccount.com \ --role roles/storage.objectAdminroles/storage.objectAdmin提供对象的读取、写入、删除与列举权限足以覆盖 Quickwit 创建索引、写入 splits、读写 metastore 元数据、执行 GC垃圾回收删除过期 split等全部操作。第三步绑定两个 Service AccountWorkload IdentityWorkload Identity 的核心是把 GKE 集群内的身份PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]与 GCP 身份绑定并允许前者模拟后者。首先在 GCP Service Account 上授予 IAM 用户即 GKE 命名空间级身份以roles/iam.workloadIdentityUser角色。注意这里的 member 与命名空间强相关gcloud iam service-accounts add-iam-policy-binding ${GCP_SERVICE_ACCOUNT}${PROJECT_ID}.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member serviceAccount:${PROJECT_ID}.svc.id.goog[${NS}/${GKE_SERVICE_ACCOUNT}]然后在 GKE Service Account 上打上注解声明它映射到的 GCP Service Accountkubectl annotate serviceaccount ${GKE_SERVICE_ACCOUNT} \ iam.gke.io/gcp-service-account${GCP_SERVICE_ACCOUNT}${PROJECT_ID}.iam.gserviceaccount.com \ -n ${NS}完成这三步后quickwit-tutorial命名空间中名为quickwit-sa的 Pod 身份即可自动获得 GCP Service Accountquickwit-tutorial的令牌。使用 Workload Identity 的优势在于GCS 凭据由 GKE 自动轮换与注入集群内任何配置文件、Secret 中都不需要出现密钥。从源码角度印证GoogleCloudStorageConfig支持通过credential_path或环境变量QW_GOOGLE_CLOUD_STORAGE_CREDENTIAL_PATH指定服务账号 JSON 文件路径见 storage_config.rs而 google_cloud_storage.rs 中构建 opendal Gcs service 时仅在显式配置了凭据路径时才附加credential_path。也就是说不配置任何凭据时opendal 会走 GCE 元数据服务器 / ADCApplication Default Credentials链路获取短期令牌——这正是 Workload Identity 生效的机制。测试代码中还通过disable_vm_metadata()与本地 HTTPS 模拟 GCS 服务器验证了不带静态凭据的gs://请求路径。第四步安装 Quickwit Helm Chart现在可以安装 Quickwit 了。如果你需要了解 Helm 方式的完整说明需求、最小配置、PostgreSQL 元数据库等可参考仓库中的 Helm 安装指南。添加并更新 Quickwit 官方 Helm 仓库helm repo add quickwit https://helm.quickwit.io helm repo update quickwit编写 values.yaml创建values.yaml关键点有三处镜像 tag使用edge文档特别注明当时修复了一个导致 metastore 无法运行在 GCS 上的 bug因此使用带修复的 edge 版本生产环境建议评估后选择固定且已验证的版本serviceAccount关闭 chart 自动创建 SAcreate: false改用上一步创建的quickwit-saconfig通过default_index_root_uri与metastore_uri指向同一个 GCS 前缀。# We use the edge version here as we recently fixed # a bug which prevents the metastore from running on GCS. image: repository: quickwit/quickwit pullPolicy: Always tag: edge serviceAccount: create: false name: quickwit-sa config: default_index_root_uri: gs://{BUCKET}/qw-indexes metastore_uri: gs://{BUCKET}/qw-indexes关于config段的语义可以从 quickwit.yaml 模板确认metastore_uri定义元数据库位置。gs://是文件型file-backedmetastore 的存储根每个索引的元数据存放在[storage_uri]/[index_id]/metastore.json详见 metastore-config.md。默认值是本地data_dir/indexes仅适合单机测试集群部署必须显式指向共享对象存储default_index_root_uri定义索引数据splits的存放根索引 URI 形如{default_index_root_uri}/{index-id}。默认同样是本地{data_dir}/indexes。部署helm install deployment name quickwit/quickwit -f values.yamldeployment name请替换为实际部署名例如quickwit。若此前已用helm show values quickwit/quickwit查看过 chart 默认值会发现config段正是透传给节点配置文件的其字段与 node 配置一一对应。第五步验证 Quickwit 运行状态集群启动通常需要数秒。启动过程中个别 Pod 可能会重启若干次例如等待 GCS 连接、元数据初始化完成这属于正常现象无需干预。用端口转发把 Searcher 服务的 7280 端口暴露到本地7280 是 Quickwit REST API 与 UI 的默认端口见 ports-config.mdkubectl port-forward svc/release-name-quickwit-searcher 7280:7280然后打开浏览器访问 http://localhost:7280 即可看到 Quickwit UI。同一端点也是 REST API 的入口例如可以通过curl http://localhost:7280/api/v1/version校验集群是否就绪或在 UI 中创建索引并写入测试数据。第六步卸载部署需要清理时运行helm uninstall deployment name卸载只删除 Kubernetes 资源不会删除 GCS 中的对象。Quickwit 会在gs://{BUCKET}/qw-indexes下写入若干文件索引配置、metastore 元数据等文档提示通常约 3 个文件。如需彻底清理请手动清空 Bucket 中的qw-indexes前缀避免残留存储产生费用。深入Quickwit 如何解析与认证gs://URI结合源码可以完整还原一次 GCS 访问的调用链URI 解析GoogleCloudStorageFactory::resolve调用parse_google_uri使用正则gs(\[^:])?://(?Pbucket[^/])(/(?Pprefix.*))?$从gs://bucket/prefix中提取 Bucket 名与路径前缀google_cloud_storage.rs凭据装配若配置了credential_path或环境变量QW_GOOGLE_CLOUD_STORAGE_CREDENTIAL_PATH则把它传给 opendal否则依赖环境自动发现凭据GKE Workload Identity 场景下即为 GCE 元数据服务# 备用方案显式挂载服务账号 JSON不推荐Workload Identity 更优 storage: google: credential_path: /path/to/credential.json存储构建用 Bucket 名与前缀构造opendal::services::Gcs再由OpendalStorage::new_google_cloud_storage包装为 Quickwit 统一的Storagetrait 对象带防抖缓存DebouncedStorage协议分派所有gs://URI 在 storage_resolver.rs 中统一映射到StorageBackend::Google工厂与s3://、azure://、file://并存。另外值得注意的是如果未来你需要把 GCS 当作 S3 兼容端点访问例如某些历史工具链Quickwit 的 S3 存储配置也提供了flavor: gcs它会自动关闭多对象删除、分片上传并禁用校验和见 storage-config.md。但本指南的场景GKE Workload Identity走的是原生gs://协议无需这些兼容开关。总结在 GKE 上运行 Quickwit 的关键路径可以浓缩为三步建身份GCP GKE 双 Service Account 并通过 Workload Identity 绑定、授权限roles/storage.objectAdminroles/iam.workloadIdentityUser、指存储values.yaml中把metastore_uri与default_index_root_uri指向同一 GCS 前缀。这套方案全程无静态密钥凭据由 GKE 自动管理安全且可复现。如果你需要进一步了解集群级配置如 PostgreSQL 元数据库、S3 存储仓库中的 Helm 指南、存储配置 与 元数据库配置 是很好的后续阅读材料。【免费下载链接】quickwitCloud-native OSS search engine for observability项目地址: https://gitcode.com/GitHub_Trending/qu/quickwit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 在 Google GKE 上部署 Quickwit：Workload Identity 与 GCS 对象存储配置实战
在 Google GKE 上部署 QuickwitWorkload Identity 与 GCS 对象存储配置实战【免费下载链接】quickwitCloud-native OSS search engine for observability项目地址: https://gitcode.com/GitHub_Trending/qu/quickwit本指南以 Quickwit 官方 Kubernetes 部署文档为核心完整演示如何在 Google Kubernetes EngineGKE上通过 Helm 部署一个使用 Google Cloud StorageGCS作为索引与元数据存储的 Quickwit 集群。你将掌握 GCP Service Account 与 GKE Service Account 的绑定Workload Identity、正确的 IAM 权限授予、values.yaml配置编写以及部署后的验证与卸载流程并了解 Quickwit 底层如何解析gs://URI 与认证凭据。背景为什么在 GKE 上部署 Quickwit 需要专门配置Quickwit 是云原生的可观测性搜索引擎其核心设计是存储与计算分离索引数据splits与元数据统一存放在对象存储中节点自身不持久化索引。因此在 GKE 上部署 Quickwit 的第一步不是写 Deployment而是解决节点访问对象存储的权限问题。Quickwit 原生支持 Google Cloud StorageGCSAPI这一能力自 0.7 版本起提供更早版本需要使用 S3 互操作密钥。其底层通过 opendal 的 GCS service 与gs://协议对接源码位置见 google_cloud_storage.rs。从 storage_resolver.rs 可以看到StorageResolver::resolve会根据 URI 的协议Protocol::Google将gs://请求分发给GoogleCloudStorageFactory并在编译特性gcs未开启时返回明确的Quickwit was compiled without thegcsfeature错误——这意味着你使用的官方镜像已内置 GCS 支持无需额外编译。本指南采用 GKE 官方推荐的Workload Identity方案通过 GKE Service Account 与 GCP Service Account 的绑定让集群内的 Pod 自动获得访问 GCS 的短期凭据无需在配置中硬编码任何密钥。前置准备在开始之前请确认环境满足以下条件一个可用的 GKE 集群且已配置好kubectl上下文版本与集群相差不超过一个 minor 版本可用kubectl version校验Helm v3 已安装helm version校验gcloud命令行工具已安装并登录gcloud auth login目标 GCS Bucket 已创建本指南以your-bucket为例。第一步创建命名空间与 Service Account首先创建用于本次演练的命名空间本指南使用quickwit-tutorialexport NSquickwit-tutorial kubectl create ns ${NS}接下来需要两个 Service AccountGCP Service Accountquickwit-tutorialGCP 层面的身份拥有访问 GCS Bucket 的权限GKE Service Accountquickwit-saKubernetes 层面的身份供 Quickwit Pod 使用通过注解绑定到前者。创建 GKE Service Account 并注册 GCP Service Accountexport PROJECT_ID{your-project-id} export GCP_SERVICE_ACCOUNTquickwit-tutorial export GKE_SERVICE_ACCOUNTquickwit-sa export BUCKETyour-bucket kubectl create serviceaccount ${GKE_SERVICE_ACCOUNT} -n ${NS} gcloud iam service-accounts create ${GCP_SERVICE_ACCOUNT} --project${PROJECT_ID}第二步授予 GCS Bucket 权限为 GCP Service Account 授予目标 Bucket 的对象管理权限gcloud storage buckets add-iam-policy-binding gs://${BUCKET} \ --member serviceAccount:${GCP_SERVICE_ACCOUNT}${PROJECT_ID}.iam.gserviceaccount.com \ --role roles/storage.objectAdminroles/storage.objectAdmin提供对象的读取、写入、删除与列举权限足以覆盖 Quickwit 创建索引、写入 splits、读写 metastore 元数据、执行 GC垃圾回收删除过期 split等全部操作。第三步绑定两个 Service AccountWorkload IdentityWorkload Identity 的核心是把 GKE 集群内的身份PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]与 GCP 身份绑定并允许前者模拟后者。首先在 GCP Service Account 上授予 IAM 用户即 GKE 命名空间级身份以roles/iam.workloadIdentityUser角色。注意这里的 member 与命名空间强相关gcloud iam service-accounts add-iam-policy-binding ${GCP_SERVICE_ACCOUNT}${PROJECT_ID}.iam.gserviceaccount.com \ --role roles/iam.workloadIdentityUser \ --member serviceAccount:${PROJECT_ID}.svc.id.goog[${NS}/${GKE_SERVICE_ACCOUNT}]然后在 GKE Service Account 上打上注解声明它映射到的 GCP Service Accountkubectl annotate serviceaccount ${GKE_SERVICE_ACCOUNT} \ iam.gke.io/gcp-service-account${GCP_SERVICE_ACCOUNT}${PROJECT_ID}.iam.gserviceaccount.com \ -n ${NS}完成这三步后quickwit-tutorial命名空间中名为quickwit-sa的 Pod 身份即可自动获得 GCP Service Accountquickwit-tutorial的令牌。使用 Workload Identity 的优势在于GCS 凭据由 GKE 自动轮换与注入集群内任何配置文件、Secret 中都不需要出现密钥。从源码角度印证GoogleCloudStorageConfig支持通过credential_path或环境变量QW_GOOGLE_CLOUD_STORAGE_CREDENTIAL_PATH指定服务账号 JSON 文件路径见 storage_config.rs而 google_cloud_storage.rs 中构建 opendal Gcs service 时仅在显式配置了凭据路径时才附加credential_path。也就是说不配置任何凭据时opendal 会走 GCE 元数据服务器 / ADCApplication Default Credentials链路获取短期令牌——这正是 Workload Identity 生效的机制。测试代码中还通过disable_vm_metadata()与本地 HTTPS 模拟 GCS 服务器验证了不带静态凭据的gs://请求路径。第四步安装 Quickwit Helm Chart现在可以安装 Quickwit 了。如果你需要了解 Helm 方式的完整说明需求、最小配置、PostgreSQL 元数据库等可参考仓库中的 Helm 安装指南。添加并更新 Quickwit 官方 Helm 仓库helm repo add quickwit https://helm.quickwit.io helm repo update quickwit编写 values.yaml创建values.yaml关键点有三处镜像 tag使用edge文档特别注明当时修复了一个导致 metastore 无法运行在 GCS 上的 bug因此使用带修复的 edge 版本生产环境建议评估后选择固定且已验证的版本serviceAccount关闭 chart 自动创建 SAcreate: false改用上一步创建的quickwit-saconfig通过default_index_root_uri与metastore_uri指向同一个 GCS 前缀。# We use the edge version here as we recently fixed # a bug which prevents the metastore from running on GCS. image: repository: quickwit/quickwit pullPolicy: Always tag: edge serviceAccount: create: false name: quickwit-sa config: default_index_root_uri: gs://{BUCKET}/qw-indexes metastore_uri: gs://{BUCKET}/qw-indexes关于config段的语义可以从 quickwit.yaml 模板确认metastore_uri定义元数据库位置。gs://是文件型file-backedmetastore 的存储根每个索引的元数据存放在[storage_uri]/[index_id]/metastore.json详见 metastore-config.md。默认值是本地data_dir/indexes仅适合单机测试集群部署必须显式指向共享对象存储default_index_root_uri定义索引数据splits的存放根索引 URI 形如{default_index_root_uri}/{index-id}。默认同样是本地{data_dir}/indexes。部署helm install deployment name quickwit/quickwit -f values.yamldeployment name请替换为实际部署名例如quickwit。若此前已用helm show values quickwit/quickwit查看过 chart 默认值会发现config段正是透传给节点配置文件的其字段与 node 配置一一对应。第五步验证 Quickwit 运行状态集群启动通常需要数秒。启动过程中个别 Pod 可能会重启若干次例如等待 GCS 连接、元数据初始化完成这属于正常现象无需干预。用端口转发把 Searcher 服务的 7280 端口暴露到本地7280 是 Quickwit REST API 与 UI 的默认端口见 ports-config.mdkubectl port-forward svc/release-name-quickwit-searcher 7280:7280然后打开浏览器访问 http://localhost:7280 即可看到 Quickwit UI。同一端点也是 REST API 的入口例如可以通过curl http://localhost:7280/api/v1/version校验集群是否就绪或在 UI 中创建索引并写入测试数据。第六步卸载部署需要清理时运行helm uninstall deployment name卸载只删除 Kubernetes 资源不会删除 GCS 中的对象。Quickwit 会在gs://{BUCKET}/qw-indexes下写入若干文件索引配置、metastore 元数据等文档提示通常约 3 个文件。如需彻底清理请手动清空 Bucket 中的qw-indexes前缀避免残留存储产生费用。深入Quickwit 如何解析与认证gs://URI结合源码可以完整还原一次 GCS 访问的调用链URI 解析GoogleCloudStorageFactory::resolve调用parse_google_uri使用正则gs(\[^:])?://(?Pbucket[^/])(/(?Pprefix.*))?$从gs://bucket/prefix中提取 Bucket 名与路径前缀google_cloud_storage.rs凭据装配若配置了credential_path或环境变量QW_GOOGLE_CLOUD_STORAGE_CREDENTIAL_PATH则把它传给 opendal否则依赖环境自动发现凭据GKE Workload Identity 场景下即为 GCE 元数据服务# 备用方案显式挂载服务账号 JSON不推荐Workload Identity 更优 storage: google: credential_path: /path/to/credential.json存储构建用 Bucket 名与前缀构造opendal::services::Gcs再由OpendalStorage::new_google_cloud_storage包装为 Quickwit 统一的Storagetrait 对象带防抖缓存DebouncedStorage协议分派所有gs://URI 在 storage_resolver.rs 中统一映射到StorageBackend::Google工厂与s3://、azure://、file://并存。另外值得注意的是如果未来你需要把 GCS 当作 S3 兼容端点访问例如某些历史工具链Quickwit 的 S3 存储配置也提供了flavor: gcs它会自动关闭多对象删除、分片上传并禁用校验和见 storage-config.md。但本指南的场景GKE Workload Identity走的是原生gs://协议无需这些兼容开关。总结在 GKE 上运行 Quickwit 的关键路径可以浓缩为三步建身份GCP GKE 双 Service Account 并通过 Workload Identity 绑定、授权限roles/storage.objectAdminroles/iam.workloadIdentityUser、指存储values.yaml中把metastore_uri与default_index_root_uri指向同一 GCS 前缀。这套方案全程无静态密钥凭据由 GKE 自动管理安全且可复现。如果你需要进一步了解集群级配置如 PostgreSQL 元数据库、S3 存储仓库中的 Helm 指南、存储配置 与 元数据库配置 是很好的后续阅读材料。【免费下载链接】quickwitCloud-native OSS search engine for observability项目地址: https://gitcode.com/GitHub_Trending/qu/quickwit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考