kOpsKubernetes 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 是什么一个为集群而生的 kubectlkOps 的全称是Kubernetes Operations项目定位于“The easiest way to get a production grade Kubernetes cluster up and running”——以最简单的方式让生产级 Kubernetes 集群跑起来。项目维护在 README.md当前仓库即为 kOps 的完整源码实现包含cmd/kopsCLI 入口、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 当前对云厂商的支持分级如下状态云厂商官方支持OfficialAWSAmazon Web Services、GCEGoogle Cloud PlatformBeta 支持DigitalOcean、Hetzner、OpenStackAlpha 支持Azure其中 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 GroupsASG每个实例由 AWS 自动监控一旦故障即自动重建。这意味着控制平面与工作节点天然具备自愈能力详细说明见 docs/getting_started/aws.md。多主高可用的进阶部署示例记录在 docs/operations/high_availability.md。基于状态同步模型dry-run 与幂等性kOps 的核心架构围绕state-sync状态同步模型构建dry-runkops update cluster默认只输出将要执行的变更计划确认无误后加上--yes才真正生效避免误操作自动幂等idempotency重复执行相同命令不会产生重复资源集群状态与期望状态持续收敛。这一设计在 docs/state.md 中有明确阐述kOps 的“状态存储state store”是集群配置的唯一事实来源source of truth配置不仅在建集群时写入之后任何修改都会再次写入并可应用到运行中的集群。命令行参数本质上是“编辑配置的快捷方式”——例如--node-sizem4.large等价于在配置中写入NodeMachineType: m4.large参数会与既有配置合并这也正是“只改参数就能重新配置集群”的原理。生成 Terraform 配置kOps 可以导出基础设施的 Terraform 描述文件让用户用自己熟悉的 Terraform 工作流code review、plan/apply、团队协作来管理 kOps 集群的底层云资源。用法与细节见 docs/terraform.md。零配置托管插件Add-onskOps 内置大量托管型插件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/ 目录其中ClusterSpecpkg/apis/kops/cluster.go是集群的顶层配置结构涵盖Channel集群跟随的 channelConfigStore节点获取配置的存储config store配置CloudProvider云提供商配置KubernetesVersion要安装的 Kubernetes 版本可为stable这类 specDNSZone使用的 DNS 托管区域ClusterDNSDomain集群内部 DNS 后缀默认cluster.localSSHAccess/NodePortAccessSSH 与 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 VPCaws-vpc.mdCalicocalico.mdCiliumcilium.mdFlannelflannel.mdIPv6ipv6.mdkindnetkindnet.mdkube-routerkube-router.md多架构支持与 ARM64kOps 具备多架构就绪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 与 LinuxHomebrewbrew update brew install kopsLinuxGitHub 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/kopsmacOSGitHub 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/kopsWindows从 Releases 下载kops-windows-amd64重命名为kops.exe并放入任意目录将该目录加入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域名购自 AWSRoute53 中已有托管区域直接使用即可无需额外操作场景 1bAWS 域名下的子域在 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(.Nameexample.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 集群--dnsnone未指定 DNS 区域时的默认值可以跳过整个 DNS 配置小节。验证 DNS 设置dig ns subdomain.example.com输出应包含 AWS 的 4 条 NS 记录。官方文档特别强调Kubernetes API 起不来的常见原因就是集群 DNS 配置错误请务必在继续前完成 NS 记录校验。第三步创建状态存储State StorekOps 需要一个 S3 桶来存储集群状态与配置表示该桶是集群配置的唯一事实来源。建议桶创建在us-east-1区域并强烈建议开启版本控制以便回滚或恢复历史状态aws s3api create-bucket \ --bucket prefix-example-com-state-store \ --region us-east-1 # 注意非 us-east-1 区域需附带 --create-bucket-configuration LocationConstraintregion aws s3api put-bucket-versioning --bucket prefix-example-com-state-store --versioning-configuration StatusEnabledOIDC 存储桶若要让 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 BlockPublicAclsfalse,IgnorePublicAclsfalse,BlockPublicPolicyfalse,RestrictPublicBucketsfalse aws s3api put-bucket-acl \ --bucket prefix-example-com-oidc-store \ --acl public-read状态存储加密与跨账户共享默认桶加密若 S3 桶配置了默认加密kOps 会直接使用未配置时 kOps 自动回退到 SSE-S3AES256加密跨账户共享单个 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。状态存储的位置按优先级可通过四种方式指定命令行参数--state s3://yourstatestore环境变量export KOPS_STATE_STOREs3://yourstatestore配置文件$HOME/.kops.yaml配置文件$HOME/.kops/config内容形如kops_state_store: s3://yourstatestore第四步创建第一个集群准备本地环境变量export NAMEmyfirstcluster.example.com export KOPS_STATE_STOREs3://prefix-example-com-state-storeNone-DNS 集群则不需要已注册域名例如export NAMEmyfirstcluster.k8s.local也可以不设环境变量改用--name与--state标志传值。生成集群配置dry-run先确认可用的可用区AZ再生成集群配置。注意以下命令只生成配置不会真正开始构建基础设施aws ec2 describe-availability-zones --region us-west-2 kops create cluster \ --name${NAME} \ --cloudaws \ --zonesus-west-2a \ --discovery-stores3://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/configkubectl 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考