基于目前kubernetes已经完全上生产环境，为了保证业务稳定安全的运行，以及遵循已经制定好的规范需要对需要部署的程序进行一些必要的检查。
本文承接维护Jenkins job, 在基础CI运行环境的基础上，在CI中运行相关规范的检验，检验通过后才可以部署到kubernetes集群中。
requirements
Jenkins2.121+
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 <<EOF > 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中都需要配置livenessProbe 和 readinessProbe探针。为了保证服务的可用性，根据业务的特点选择探针的方式，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的limits和 requests。
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，
