kOps 附加组件 ¶
kOps 支持两种类型的附加组件
- 托管附加组件,可以通过 集群规范 配置
- 静态附加组件,它们是按原样应用的清单文件
托管附加组件 ¶
以下附加组件由 kOps 管理,并将根据 kOps 和 kubernetes 生命周期进行升级,并根据您的集群规范进行配置。kOps 将同时考虑附加组件本身的配置以及您可能在适用时配置的其他设置。
可用附加组件 ¶
AWS Load Balancer 控制器 ¶
推出 |
---|
kOps 1.20 |
AWS Load Balancer 控制器为配置 ELB 提供了额外的功能。
spec:
awsLoadBalancerController:
enabled: true
虽然 AWS Load Balancer 控制器可以将 AWS WAF 和 Shield 服务与您的应用程序负载均衡器 (ALB) 集成,但 kOps 默认情况下会禁用这些功能。
推出 |
---|
kOps 1.24 |
您可以通过在集群规范中包含以下字段来启用 WAF 或 WAF Classic 服务的使用
spec:
awsLoadBalancerController:
enabled: true
enableWAF: true
enableWAFv2: true
请注意,尽管控制器接受在同一个 Ingress 对象上使用 "alb.ingress.kubernetes.io/waf-acl-id" 和 "alb.ingress.kubernetes.io/wafv2-acl-arn" 注释,但它一次只能成功地将一个 WAF 与给定的 ALB 关联。
您可以通过在集群规范中包含以下字段来启用 Shield Advanced 的使用
spec:
awsLoadBalancerController:
enabled: true
enableShield: true
kOps 中对 WAF 和 Shield 服务的支持目前处于 beta 阶段,这意味着接受的配置和涉及的 AWS 资源可能会发生变化。
在 官方文档 中了解更多信息。
集群自动扩展器 ¶
推出 |
---|
kOps 1.19 |
可以启用集群自动扩展器来自动调整 kubernetes 集群的大小。
spec:
clusterAutoscaler:
enabled: true
expander: least-waste
balanceSimilarNodeGroups: false
awsUseStaticInstanceList: false
scaleDownUtilizationThreshold: 0.5
skipNodesWithCustomControllerPods: true
skipNodesWithLocalStorage: true
skipNodesWithSystemPods: true
newPodScaleUpDelay: 0s
scaleDownDelayAfterAdd: 10m0s
scaleDownUnneededTime: 10m0s
scaleDownUnreadyTime: 20m0s
image: <the latest supported image for the specified kubernetes version>
cpuRequest: "100m"
memoryRequest: "300Mi"
在 官方文档 中详细了解集群自动扩展器。
扩展策略 ¶
集群自动扩展器支持多种不同的 扩展策略。
优先级扩展器配置 ¶
推出 |
---|
kOps 1.26 |
priority
扩展器需要通过 ConfigMap 进行额外的配置,如 其文档 中所述
当定义了 expander: priority
时,kOps 将根据实例组规范创建此 ConfigMap。您可以通过在实例组规范中添加以下内容来更改每个实例组的优先级。
spec:
autoscale: true
autoscalePriority: 100
如果未设置 autoscalePriority
,则它将默认为 0。
如果您需要更复杂的配置,例如使用正则表达式匹配实例组,则可以提供您自己的自定义配置。如果配置了此配置,则会忽略实例组规范中设置的优先级。
clusterAutoscaler:
customPriorityExpanderConfig:
100:
- .*foo.*
50:
- .*bar.*
0:
- .*
禁用 ¶
如果您想在 kOps 之外管理优先级扩展器 ConfigMap,则可以通过在集群规范中添加以下内容来禁用 ConfigMap 创建
clusterAutoscaler:
createPriorityExpanderConfig: false
为特定实例组禁用集群自动扩展器 ¶
推出 |
---|
kOps 1.20 |
您可以通过在实例组规范中添加以下内容来为特定实例组禁用自动扩展器。
spec:
autoscale: false
Cert-manager ¶
推出 | 最低 K8s 版本 |
---|---|
kOps 1.20 | k8s 1.16 |
Cert-manager 处理集群的 x509 证书。
spec:
certManager:
enabled: true
defaultIssuer: yourDefaultIssuer
警告:cert-manager 每个集群只支持一个安装。如果您已经运行了 cert-manager,则需要在启用此附加组件之前将其删除,或者将 cert-manger 标记为不受 kOps 管理(见下文)。只要您使用的是 cert-manager 资源的 v1 版本,就可以安全地删除现有安装并将其替换为此附加组件
自配置 cert-manager ¶
推出 | 最低 K8s 版本 |
---|---|
kOps 1.20.2 | k8s 1.16 |
以下 cert-manager 配置允许在外部配置 cert-manager,并允许部署所有依赖插件。请注意,在部署 cert-manager 之前,附加组件可能会遇到错误。
spec:
certManager:
enabled: true
managed: false
cert-manager Pod 的 DNS 服务器配置 ¶
推出 | 最低 K8s 版本 |
---|---|
kOps 1.23.3 | k8s 1.16 |
cert-manager Pod 要使用的 DNS 服务器 IP 地址的可选列表。如果您对同一个域有公共和私有 DNS 区域,这将很有用,以确保 cert-manager 始终可以访问 ingress 或 DNS01 挑战 TXT 记录。
您可以像这样设置 cert-manager 的 Pod DNS 服务器配置
spec:
certManager:
enabled: true
nameservers:
- 1.1.1.1
- 8.8.8.8
启用 dns-01 挑战 ¶
推出 |
---|
kOps 1.25.0 |
Cert Manager 可以通过添加托管区域 ID 列表获得解决 dns-01 挑战所需的 IAM 权限。这需要 服务帐户的外部权限 才能启用。
spec:
certManager:
enabled: true
hostedZoneIDs:
- ZONEID
iam:
useServiceAccountExternalPermissions: true
在 官方文档 中详细了解 cert-manager
Karpenter ¶
推出 |
---|
kOps 1.24 |
Karpenter 附加组件启用 Karpenter 管理的实例组。
spec:
karpenter:
enabled: true
在 kOps Karpenter 文档 和 官方文档 中查看有关如何配置 Karpenter 的更多详细信息
指标服务器 ¶
推出 |
---|
kOps 1.19 |
指标服务器是 Kubernetes 内置自动扩展管道中容器资源指标的可扩展高效来源。
spec:
metricsServer:
enabled: true
在 官方文档 中详细了解指标服务器。
安全 TLS ¶
推出 |
---|
kOps 1.20 |
默认情况下,API 服务器不会验证指标服务器 TLS 证书。要启用 TLS 验证,请在集群规范中设置以下内容
spec:
certManager:
enabled: true
metricsServer:
enabled: true
insecure: false
这需要在集群中安装 cert-manager。
节点本地 DNS 缓存 ¶
推出 | 最低 K8s 版本 |
---|---|
kOps 1.18 | k8s 1.15 |
如果您使用的是 CoreDNS,则可以启用 NodeLocal DNSCache。它用于通过在集群节点上作为 DaemonSet 运行 dns 缓存代理来提高集群 DNS 性能。
还可以配置 node-local-dns
Pod 的 memoryRequest
和 cpuRequest
。如果未设置,它们将分别默认为 5Mi
和 25m
。
如果启用了 forwardToKubeDNS
,则 kubedns 将用作默认上游
spec:
kubeDNS:
provider: CoreDNS
nodeLocalDNS:
enabled: true
memoryRequest: 5Mi
cpuRequest: 25m
节点终止处理程序 ¶
推出 |
---|
kOps 1.19 |
节点终止处理程序 确保 Kubernetes 控制平面对可能导致您的 EC2 实例不可用的事件做出适当的响应,例如 EC2 维护事件、EC2 竞价型实例中断和 EC2 实例重新平衡建议。如果未处理,您的应用程序代码可能无法正常停止、恢复完整可用性所需时间更长或意外地将工作调度到即将关闭的节点。
spec:
nodeTerminationHandler:
cpuRequest: 200m
enabled: true
enableRebalanceMonitoring: true
enableSQSTerminationDraining: true
managedASGTag: "aws-node-termination-handler/managed"
prometheusEnable: true
webhookURL: "https://hooks.slack.com/services/YOUR/SLACK/URL"
队列处理器模式 ¶
推出 |
---|
kOps 1.21 |
如果 enableSQSTerminationDraining
不是 false,节点终止处理程序将以队列处理器模式运行。除了上面提到的事件之外,队列处理器模式还允许节点终止处理程序处理 ASG 缩容、AZ 重新平衡、不健康的实例、通过 API 或控制台终止 EC2 实例等等。kOps 将配置必要的基础设施:一个 SQS 队列、EventBridge 规则和 ASG 生命周期挂钩。managedASGTag
可以与队列处理器模式一起配置,以区分多个集群之间的资源所有权。
kOps CLI 需要额外的 IAM 权限才能管理必要的 EventBridge 规则和 SQS 队列。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"events:DeleteRule",
"events:ListRules",
"events:ListTargetsByRule",
"events:ListTagsForResource",
"events:PutEvents",
"events:PutRule",
"events:PutTargets",
"events:RemoveTargets",
"events:TagResource",
"sqs:CreateQueue",
"sqs:TagQueue",
"sqs:DeleteQueue",
"sqs:GetQueueAttributes",
"sqs:ListQueues",
"sqs:ListQueueTags"
],
"Resource": "*"
}
]
}
警告: 如果您在现有集群上在两种操作模式之间切换,则必须手动删除旧资源。对于从 IMDS 到队列处理器的切换,这意味着删除 k8s nth 守护程序集。对于从队列处理器到 IMDS 的切换,这意味着删除 Kubernetes NTH 部署和 AWS 资源:SQS 队列、EventBridge 规则和 ASG 生命周期挂钩。
节点问题检测器 ¶
推出 |
---|
kOps 1.22 |
节点问题检测器 旨在使集群管理堆栈中上游层可见各种节点问题。它是一个在每个节点上运行的守护程序,检测节点问题并将其报告给 apiserver。
spec:
nodeProblemDetector:
enabled: true
memoryRequest: 32Mi
cpuRequest: 10m
Pod 身份 Webhook ¶
推出 |
---|
kOps 1.23 |
当使用 用于服务帐户的 IAM 角色 (IRSA) 时,Pod 需要额外的令牌才能对 AWS API 进行身份验证。此外,SDK 需要设置特定的环境变量才能使用这些令牌。此附加组件将修改配置为使用 IRSA 的 Pod,以便用户无需自己执行此操作。
在集群规范中配置了 AWS 权限的所有服务帐户将自动被修改以承担配置的角色。
spec:
certManager:
enabled: true
podIdentityWebhook:
enabled: true
服务帐户上的 EKS 注释通常不是必需的,因为 kOps 会将所有服务帐户与集群规范中配置的角色映射的 webhook 配置好。但如果您需要特定配置,可以注释服务帐户,覆盖 kOps 配置。
在 官方文档 中阅读有关 Pod 身份 Webhook 的更多信息。
快照控制器 ¶
推出 | 最低 K8s 版本 |
---|---|
kOps 1.21 | k8s 1.20 |
快照控制器实现 容器存储接口 (CSI) 的卷快照功能。
您可以通过将以下内容添加到集群规范来启用快照控制器
spec:
snapshotController:
enabled: true
请注意,树内卷驱动程序不支持此功能。如果您在 AWS 上运行集群,可以通过添加以下内容来启用 EBS CSI 驱动程序
spec:
cloudConfig:
awsEBSCSIDriver:
enabled: true
自管理 aws-ebs-csi-driver ¶
推出 |
---|
kOps 1.25 |
以下配置允许使用自管理 aws-ebs-csi-driver。请注意,如果您使用的是 Amazon EBS 卷,则必须安装 Amazon EBS CSI 驱动程序。如果未安装 Amazon EBS CSI 插件,则卷操作将失败。
如果未启用 IRSA,控制平面将具有配置节点的权限,并且自管理控制器应在控制平面上运行。如果启用了 IRSA,kOps 将创建相应的 AWS IAM 角色,分配策略,并建立信任关系,允许服务帐户承担 IAM 角色。要配置 Pod 以承担给定的 IAM 角色,请启用 Pod 身份 Webhook。没有此 webhook,您需要自己修改 Pod 规范才能让您的 Pod 承担定义的角色。
spec:
cloudConfig:
awsEBSCSIDriver:
enabled: true
managed: false
自定义附加组件 ¶
命令 kops create cluster
不支持指定在创建集群时要添加到集群的附加组件。相反,它们可以在创建集群后使用 kubectl 添加。或者,在从 yaml 清单创建集群时,可以使用 spec.addons
指定附加组件。
spec:
addons:
- manifest: s3://my-kops-addons/addon.yaml
有关 附加组件管理 的文档更详细地描述了如何定义与版本控制相关的附加组件资源。这是一个安装两个不同附加组件的附加组件清单的最小示例。
kind: Addons
metadata:
name: example
spec:
addons:
- name: foo.addons.org.io
version: 0.0.1
selector:
k8s-addon: foo.addons.org.io
manifest: foo.addons.org.io/v0.0.1.yaml
- name: bar.addons.org.io
version: 0.0.1
selector:
k8s-addon: bar.addons.org.io
manifest: bar.addons.org.io/v0.0.1.yaml
在这个例子中,文件夹结构应该看起来像这样;
addon.yaml
foo.addons.org.io
v0.0.1.yaml
bar.addons.org.io
v0.0.1.yaml
foo/bar 文件夹中的 yaml 文件可以是任何 kubernetes 资源。通常,此文件结构将被推送到 S3 或其他支持的后端,然后像上面那样在 spec.addons
中引用。为了让主节点能够访问包含附加组件清单的 S3 存储桶,您可能需要使用 spec.additionalPolicies
为主节点添加额外的 iam 策略,如下所示
spec:
additionalPolicies:
master: |
[
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": ["arn:aws:s3:::my-kops-addons/*"]
},
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket"
],
"Resource": ["arn:aws:s3:::my-kops-addons"]
}
]