kubernetes最佳实践

基于目前kubernetes已经完全上生产环境,为了保证业务稳定安全的运行,以及遵循已经制定好的规范需要对需要部署的程序进行一些必要的检查。

本文承接维护Jenkins job, 在基础CI运行环境的基础上,在CI中运行相关规范的检验,检验通过后才可以部署到kubernetes集群中。

requirements

  • Jenkins2.121+

  • argocd v1.1.1+

Directory

$ tree -L 1
.
├── README.md 
├── bin                 # 脚本存放目录
├── cluster-bootstrap   # 初始化集群需要进行的操作
├── deploy              # 最终部署到argocd使用的资源文件
├── doc                 # 相关文档存放目录
├── kubernetes 
├── requirements.txt    # Python脚本需要的依赖包文件
├── tools               # Python使用的公共包
└── workload            # Helm资源文件存放目录 

8 directories, 2 files

Deployment

Provision

要提供一个新的workload,例如example-server,至少要添加这些文件:

  • workload/example-server/helmfile.yaml,里面包含了部署的集群以及对应的values信息。
  • workload/example-server, 该目录下尊许Helm相关的格式规范,相信请查看Helm相关的文档。

然后运行bin/generate-argo来创建每个集群的部署清单,并确保它通过CI检测。

你可以使用workload/debug-tools作为模板或例子创建一个新的服务。

也可以使用下面的命令进行初始化。

$ helm create example-server

$ touch example-server/helmfile.yaml

$ cat < example-server/helmfile.yaml
name: debug-tools 
environment: 
  - name: prod
    namespace: devops 
    values: values-production.yaml 
    cluster: 53zaixian-infra  
EOF

CI检测使用/bin/validate-conf,必须完全遵守下面的最佳实践.

Ports

workload应该使用大于1024的端口。例如,替换掉默认的80端口, 将监听端口替换为8080。这允许workload以更少的权限运行。

Probes

每一个pod中都需要配置livenessProbereadinessProbe探针。为了保证服务的可用性,根据业务的特点选择探针的方式,http的业务选择HTTPGetAcction, TCP的选择TCPSocketAction, 更多细节可参阅kubernetes健康检测探针

Priority

应当根据集群中服务的特点来定义pod的优先级, 集群正常时这并没有什么作用,当集群存在故障或者负载情况异常时它可以保证集群相对的安全。 划分为三个等级

  • cluster-critical
  • service-critical
  • service-cron

说明:
Kubernetes 已经提供了 2 个 PriorityClass: system-cluster-critical 和 system-node-critical。 这些是常见的类,用于确保始终优先调度关键组件。

定义方式如下:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: cluster-critical
value: 1000
globalDefault: false
description: "Critical services running in non-kube-system namespace, e.g., nginx."

PriorityClass 对象元数据中的name指定名称,value字段为必填字段,用于指定优先级的数值, 数值越大,优先级越高。

通过字面我们可以理解cluster-critical优先级最高,其次是service-critical,最后是service-cron.

可以将cluster-critical的value定义为1000, service-critical的value定义为900, service-cron的value定义为800。

Resources

每一个workload中都需要配置resource的limitsrequests

Local State Storage

容器内如果需要存储必要的数据, 都必须使用带有适当回收策略的挂载持久卷。不保留存储会导致工作负载被排除,并导致CI检查失败。

Affinity & Pod Disruption Budgets

应当使用Anti-affinity 相关的规则,避免因为pod分配到一个节点上。 从而影响服务的可用性。 同时也应当考虑当存在node节点down机时,多个中断发生在同一时间。

      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - {{ service_name }}
              topologyKey: "failure-domain.beta.kubernetes.io/zone"

Security Context

根据pod的端口号, 确定security context的规则,

port大于1024

SECURITY_CONTEXT = {
    "allowPrivilegeEscalation": False,
    "readOnlyRootFilesystem": True,
    "runAsUser": 65534,
    "privileged": False,
}

port小于1024

  allowPrivilegeEscalation: false
  capabilities:
    add:
    - NET_BIND_SERVICE
    drop:
    - ALL
  privileged: false
  readOnlyRootFilesystem: true

Workloads必须能够在任何挂载路径之外的只读文件系统上运行。

Rolling Updates

滚动更新策略应向外扩展N + 1,并应设置适当的最大不可用值,以允许工作负载安全地继续服务流量。

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0

Replicas

关键服务器应该运行至少两个replicas。 CI检测强制执行的pod反亲和,当节点丢失期间,部署应保持可用。

也可以使用HorizontalPodAutoscaler,

你可能感兴趣的:(kubernetes最佳实践)