企业官网建设流程全解析

kOps（Kubernetes Operations）入门指南：生产级 Kubernetes 集群的创建、升级与管理

【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址: https://gitcode.com/gh_mirrors/kop/kops

本文基于 kOps 官方文档 docs/index.md 撰写。kOps 是 Kubernetes 官方生态中“面向集群的 kubectl”，它不仅能一键创建、销毁、升级和维护生产级高可用 Kubernetes 集群，还会同步完成底层云基础设施的编排与供给。读完本文，你将掌握 kOps 的核心设计理念（状态同步模型、幂等性与 dry-run）、完整的功能矩阵、多云的部署路径（AWS/GCE/OpenStack/DO/Hetzner/Azure），以及从安装、创建集群到验证与销毁的端到端实操流程。

kOps 是什么：一个为集群而生的 kubectl

kOps 的全称是Kubernetes Operations，项目定位于“The easiest way to get a production grade Kubernetes cluster up and running”——以最简单的方式让生产级 Kubernetes 集群跑起来。项目维护在 README.md，当前仓库即为 kOps 的完整源码实现，包含cmd/kops（CLI 入口）、pkg/apis/kops（集群配置 API）、pkg/model（各云厂商基础设施建模）等核心模块。

官方文档用一句话概括它的定位：kubectlfor clusters。kubectl 让用户以声明式方式操作单个 Kubernetes 集群，而 kOps 将同样的心智模型延伸到“集群本身”：

• 创建（create）、销毁（delete）、升级（upgrade）和维护（maintain）生产级、高可用的 Kubernetes 集群；
• 同时自动供给所需的云基础设施——VPC、子网、自动伸缩组、负载均衡、DNS 记录、IAM 权限等全部由 kOps 代为编排，用户无需逐一在云控制台手工创建。

从源码结构看，这一能力由多个子系统协作完成：CLI 入口位于 cmd/kops/main.go，负责装配镜像摘要解析器（assets.SetImageDigestResolver）与 OpenTelemetry 链路追踪；集群配置的权威定义在 pkg/apis/kops/cluster.go 的ClusterSpec结构体中，云提供商、Kubernetes 版本、DNS 区域、SSH 访问 CIDR 等一切集群属性都集中在这里。

多云支持现状

根据 docs/index.md 的官方说明，kOps 当前对云厂商的支持分级如下：

其中 AWS 与 GCE 的完整入门流程分别见 docs/getting_started/aws.md 与 docs/getting_started/gce.md，其余厂商的指南位于 docs/getting_started/ 目录下（digitalocean.md、hetzner.md、openstack.md、azure.md、scaleway.md）。

kOps 核心功能特性

自动化供给高可用（HA）集群

kOps 将“高可用”内置为默认能力而非事后插件。在 AWS 上创建集群时，所有实例都会放入Auto Scaling Groups（ASG），每个实例由 AWS 自动监控，一旦故障即自动重建。这意味着控制平面与工作节点天然具备自愈能力，详细说明见 docs/getting_started/aws.md。多主高可用的进阶部署示例记录在 docs/operations/high_availability.md。

基于状态同步模型：dry-run 与幂等性

kOps 的核心架构围绕state-sync（状态同步）模型构建：

• dry-run：kops update cluster默认只输出将要执行的变更计划，确认无误后加上--yes才真正生效，避免误操作；
• 自动幂等（idempotency）：重复执行相同命令不会产生重复资源，集群状态与期望状态持续收敛。

这一设计在 docs/state.md 中有明确阐述：kOps 的“状态存储（state store）”是集群配置的唯一事实来源（source of truth），配置不仅在建集群时写入，之后任何修改都会再次写入并可应用到运行中的集群。命令行参数本质上是“编辑配置的快捷方式”——例如--node-size=m4.large等价于在配置中写入NodeMachineType: m4.large，参数会与既有配置合并，这也正是“只改参数就能重新配置集群”的原理。

生成 Terraform 配置

kOps 可以导出基础设施的 Terraform 描述文件，让用户用自己熟悉的 Terraform 工作流（code review、plan/apply、团队协作）来管理 kOps 集群的底层云资源。用法与细节见 docs/terraform.md。

零配置托管插件（Add-ons）

kOps 内置大量托管型插件（managed addons），只需在集群 spec 中开启对应字段，kOps 就会跟随 kOps 与 Kubernetes 的版本生命周期自动安装、升级并按 spec 配置它们，见 docs/addons.md。插件分为两类：

• 托管插件（Managed addons）：通过 cluster spec 配置；
• 静态插件（Static addons）：以清单文件形式原样应用。

例如开启 AWS Load Balancer Controller 的配置片段：

spec: awsLoadBalancerController: enabled: true enableWAF: true enableWAFv2: true cpuRequest: "100m" cpuLimit: "200m" memoryRequest: "200Mi" memoryLimit: "500Mi"

从源码看，awsLoadBalancerController字段在 pkg/apis/kops/v1alpha2/cluster.go 中定义为AWSLoadBalancerController *LoadBalancerControllerSpec，并在 pkg/apis/kops/v1alpha2/conversion.go 中做了严格的厂商校验——该配置仅支持 AWS，其他云上设置会直接报错"AWS Load Balancer Controller supports only AWS"。值得注意的是，尽管 AWS Load Balancer Controller 本身支持 WAF/Shield 集成，kOps 默认关闭这些能力，需显式设置enableWAF、enableWAFv2、enableShield开启（当前为 beta 特性）。

类似的托管插件还包括 Cluster Autoscaler（支持expander扩缩容策略、scaleDownUtilizationThreshold缩容阈值、scaleDownUnneededTime等完整参数）等，全部配置项均可查阅 docs/addons.md。

命令行自动补全

kOps 为 bash、zsh、fish、powershell 提供原生自动补全，相关文档见 docs/cli/kops_completion.md 及各 shell 的补全参考（kops_completion_bash.md、kops_completion_zsh.md、kops_completion_fish.md、kops_completion_powershell.md）。

YAML 清单式 API 配置

kOps 将集群配置建模为完整的 Kubernetes-style API 对象，用户可以像管理普通 Kubernetes 资源一样，用 YAML 清单声明集群的完整期望状态，再通过kops replace -f应用。这一“Manifests And Customizing via API”的工作流详见 docs/manifests_and_customizing_via_api.md。对应的 API 类型定义集中在 pkg/apis/kops/ 目录，其中ClusterSpec（pkg/apis/kops/cluster.go）是集群的顶层配置结构，涵盖：

• Channel：集群跟随的 channel；
• ConfigStore：节点获取配置的存储（config store）配置；
• CloudProvider：云提供商配置；
• KubernetesVersion：要安装的 Kubernetes 版本（可为stable这类 spec）；
• DNSZone：使用的 DNS 托管区域；
• ClusterDNSDomain：集群内部 DNS 后缀（默认cluster.local）；
• SSHAccess/NodePortAccess：SSH 与 NodePort 端口的来源 CIDR 白名单；
• SSHKeyName：指定预先存在的 SSH 密钥；
• UpdatePolicy：升级策略（automatic默认自动应用安全更新，external交由外部系统处理）；
• ExternalPolicies：向实例组角色插入预置的托管策略。

模板化与 dry-run 生成清单

kops toolbox template提供集群清单的模板化渲染与 dry-run 模式，便于在 CI/CD 中按需生成不同环境的配置。完整用法见 docs/operations/cluster_template.md。

开箱即用的主流 CNI 网络方案

kOps 直接内置了当下最流行的 CNI 网络插件，可通过集群 spec 一键选择。当前仓库 docs/networking/ 目录下列出的方案包括：

• AWS VPC（aws-vpc.md）
• Calico（calico.md）
• Cilium（cilium.md）
• Flannel（flannel.md）
• IPv6（ipv6.md）
• kindnet（kindnet.md）
• kube-router（kube-router.md）

多架构支持与 ARM64

kOps 具备多架构就绪（multi-architecture ready）能力，原生支持ARM64节点，可在混合架构环境中同时运行 x86_64 与 ARM 实例。

通过集群清单注入容器、Hooks 与文件

用户可以在集群清单中为节点添加额外的容器（containers）、生命周期钩子（hooks）以及自定义文件（files），从而在节点启动阶段注入自定义逻辑——例如挂载 NVIDIA 驱动初始化脚本（仓库中的 hooks/nvidia-bootstrap/ 即为官方示例）。完整的 spec 说明见 docs/cluster_spec.md。

安装 kOps

安装 kOps 前需先准备好kubectl。官方提供了多种安装方式，详见 docs/getting_started/install.md。

macOS 与 Linux（Homebrew）

brew update && brew install kops

Linux（GitHub Releases 二进制）

curl -Lo kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64 chmod +x kops sudo mv kops /usr/local/bin/kops

macOS（GitHub Releases 二进制）

curl -Lo kops https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-darwin-amd64 chmod +x kops sudo mv kops /usr/local/bin/kops

Windows

1. 从 Releases 下载kops-windows-amd64；
2. 重命名为kops.exe并放入任意目录；
3. 将该目录加入Path环境变量。

以 AWS 为例的端到端实战

以下流程完整摘录自 docs/getting_started/aws.md，是 kOps 最成熟的官方部署路径。

第一步：准备 AWS 环境

首先安装 AWS CLI 并配置 API 凭证。kOps 通过 Go AWS SDK 读取凭证，因此使用 AWS 官方推荐的安全凭证注册方式即可（环境变量或~/.aws/credentials）。

为 kOps 创建专用 IAM 用户，需要以下权限：

AmazonEC2FullAccess AmazonRoute53FullAccess AmazonS3FullAccess IAMFullAccess AmazonVPCFullAccess AmazonSQSFullAccess AmazonEventBridgeFullAccess

用命令行创建用户与权限组：

aws iam create-group --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2FullAccess --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonRoute53FullAccess --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonS3FullAccess --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/IAMFullAccess --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonVPCFullAccess --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonSQSFullAccess --group-name kops aws iam attach-group-policy --policy-arn arn:aws:iam::aws:policy/AmazonEventBridgeFullAccess --group-name kops aws iam create-user --user-name kops aws iam add-user-to-group --user-name kops --group-name kops aws iam create-access-key --user-name kops

记下返回的SecretAccessKey与AccessKeyID并配置到本地：

aws configure # 填入新的 access key 和 secret key aws iam list-users # 应能看到所有 IAM 用户 # aws configure 不会导出环境变量供 kops 使用，这里手动导出 export AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id) export AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key)

第二步：配置 DNS

创建集群前需要准备 DNS 记录的位置，官方给出四种场景：

• 场景 1a（域名购自 AWS）：Route53 中已有托管区域，直接使用即可，无需额外操作；
• 场景 1b（AWS 域名下的子域）：在 Route53 中为子域创建第二个托管区域，并把子域的 NS 记录委派到父域；
• 场景 2（域名购自其他注册商，整域迁移 AWS）：按 Route53 官方域名转移指南操作；
• 场景 3（域名在其他注册商，仅子域使用 Route53）：在 Route53 创建托管区域，然后把子域的 4 条 NS 记录改到原注册商处——切勿改动顶级域的 NS 记录，否则可能使站点离线。

场景 1b 的操作命令如下（需要本地安装 jq）：

# 创建子域托管区域并获取其 NS 记录 ID=$(uuidgen) && aws route53 create-hosted-zone --name subdomain.example.com --caller-reference $ID | \ jq .DelegationSet.NameServers # 找到父域的 hosted zone id aws route53 list-hosted-zones | jq '.HostedZones[] | select(.Name=="example.com.") | .Id'

将子域的 NS 记录以 JSON 变更批次应用到父域托管区域（subdomain.json内容示例）：

{ "Comment": "Create a subdomain NS record in the parent domain", "Changes": [ { "Action": "CREATE", "ResourceRecordSet": { "Name": "subdomain.example.com", "Type": "NS", "TTL": 300, "ResourceRecords": [ {"Value": "ns-1.<example-aws-dns>-1.co.uk"}, {"Value": "ns-2.<example-aws-dns>-2.org"}, {"Value": "ns-3.<example-aws-dns>-3.com"}, {"Value": "ns-4.<example-aws-dns>-4.net"} ] } } ] }

aws route53 change-resource-record-sets \ --hosted-zone-id <parent-zone-id> \ --change-batch file://subdomain.json

公共/私有 DNS

默认假设 NS 记录公开可用；如需私有 DNS，创建集群时加--dns private；同时存在公共与私有区域时，还需用--dns-zone指定部署目标区域：

kops create cluster --dns private $NAME kops create cluster --dns private --dns-zone ZABCDEFG $NAME

注：如果创建的是 None-DNS 集群（--dns=none，未指定 DNS 区域时的默认值），可以跳过整个 DNS 配置小节。

验证 DNS 设置

dig ns subdomain.example.com

输出应包含 AWS 的 4 条 NS 记录。官方文档特别强调：Kubernetes API 起不来的常见原因就是集群 DNS 配置错误，请务必在继续前完成 NS 记录校验。

第三步：创建状态存储（State Store）

kOps 需要一个 S3 桶来存储集群状态与配置表示，该桶是集群配置的唯一事实来源。建议桶创建在us-east-1区域，并强烈建议开启版本控制以便回滚或恢复历史状态：

aws s3api create-bucket \ --bucket prefix-example-com-state-store \ --region us-east-1 # 注意：非 us-east-1 区域需附带 --create-bucket-configuration LocationConstraint=<region> aws s3api put-bucket-versioning --bucket prefix-example-com-state-store --versioning-configuration Status=Enabled

OIDC 存储桶

若要让 ServiceAccount 使用外部权限（IAM Roles for ServiceAccounts / IRSA），还需要一个承载 OIDC discovery 文档的桶。建议单独建桶，且 ACL 必须为公开（AWS STS 服务需要读取）：

aws s3api create-bucket \ --bucket prefix-example-com-oidc-store \ --region us-east-1 \ --object-ownership BucketOwnerPreferred aws s3api put-public-access-block \ --bucket prefix-example-com-oidc-store \ --public-access-block-configuration BlockPublicAcls=false,IgnorePublicAcls=false,BlockPublicPolicy=false,RestrictPublicBuckets=false aws s3api put-bucket-acl \ --bucket prefix-example-com-oidc-store \ --acl public-read

状态存储加密与跨账户共享

• 默认桶加密：若 S3 桶配置了默认加密，kOps 会直接使用；未配置时 kOps 自动回退到 SSE-S3（AES256）加密；
• 跨账户共享：单个 S3 桶可通过跨账户桶策略存储多个账户集群的状态；此时可用环境变量KOPS_STATE_S3_ACL覆盖对象 ACL（例如bucket-owner-full-control），避免受托账户写入的文件的桶主无法读取。

关于状态存储的更多细节（S3 环境变量、自定义 S3 兼容端点S3_ENDPOINT/S3_REGION/S3_ACCESS_KEY_ID/S3_SECRET_ACCESS_KEY、桶迁移、file://本地状态存储的仅 dry-run 限制等），见 docs/state.md。状态存储的位置按优先级可通过四种方式指定：

1. 命令行参数--state s3://yourstatestore
2. 环境变量export KOPS_STATE_STORE=s3://yourstatestore
3. 配置文件$HOME/.kops.yaml
4. 配置文件$HOME/.kops/config（内容形如kops_state_store: s3://yourstatestore）

第四步：创建第一个集群

准备本地环境变量

export NAME=myfirstcluster.example.com export KOPS_STATE_STORE=s3://prefix-example-com-state-store

None-DNS 集群则不需要已注册域名，例如：

export NAME=myfirstcluster.k8s.local

也可以不设环境变量，改用--name与--state标志传值。

生成集群配置（dry-run）

先确认可用的可用区（AZ），再生成集群配置。注意：以下命令只生成配置，不会真正开始构建基础设施：

aws ec2 describe-availability-zones --region us-west-2 kops create cluster \ --name=${NAME} \ --cloud=aws \ --zones=us-west-2a \ --discovery-store=s3://prefix-example-com-oidc-store/${NAME}/discovery

创建集群前请确保已生成 SSH 密钥对。

定制集群配置

kops edit cluster --name ${NAME}会用$EDITOR打开配置编辑器。配置从 S3 桶加载，保存退出后自动写回。所有参数默认值即可起步，进阶设置可参考 kOps 文档的其余章节。

真正构建集群

kops update cluster --name ${NAME} --yes --admin

此步骤耗时较长，实例启动后还需等待 Kubernetes 组件下载完成并进入 ready 状态。

使用集群

kops 已自动生成 kubectl 配置并写入~/.kube/config：

kubectl get nodes # 节点列表应与 --zones 指定的可用区匹配 kops validate cluster --wait 10m # kOps 自带的集群校验工具 kubectl -n kube-system get po # 查看所有系统组件

删除集群

先预览将被销毁的所有 AWS 资源，确认后再真正删除：

kops delete cluster --name ${NAME} # 预览（dry-run） kops delete cluster --name ${NAME} --yes # 真正删除（破坏性操作！）

集群配置的源码级全景

如果想要理解 kOps “配置即 API” 的设计，最直接的入口就是ClusterSpec结构体。它定义在 pkg/apis/kops/cluster.go，位于内部 API 包中；对外发布的版本化 API 则在 pkg/apis/kops/v1alpha2/cluster.go 与 pkg/apis/kops/v1alpha3/cluster.go。版本间的自动转换（autoConvert）逻辑集中在 pkg/apis/kops/v1alpha2/conversion.go，其中包含大量跨厂商、跨版本的合法性校验——例如前面提到的 AWS Load Balancer Controller 仅限 AWS 的强校验。这也意味着：kOps 的配置不是“写了就能用”，而是经过 API 层严格验证后才进入基础设施建模阶段。

结语与下一步

kOps 以“状态同步 + 幂等 + dry-run”为核心方法论，把生产级 Kubernetes 集群的创建、升级与运维沉淀为一条可重复、可审计、可自动化的命令流水线，并且将多云基础设施的编排与 Kubernetes 自身的声明式理念统一在同一个 YAML API 之下。

创建出第一个可用的集群之后，建议继续阅读以下官方资料深化实践：

• 生产环境部署建议（production.md）
• 高可用集群部署（high_availability.md）
• 集群升级（upgrades_and_updates.md）
• 实例组管理（instance_groups.md）
• 集群模板化（cluster_template.md）

【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址: https://gitcode.com/gh_mirrors/kop/kops