一、安全

通过安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置, Pod级别将应用到Pod中的所有容器，除非容器自身的安全上下文覆盖这些设置

1. 非root身份运行容器

...
spec:
  securityContext:
    runAsUser: 1000      #设置Pod中的所有容器运行用户
    runAsGroup: 3000     #设置Pod中的所有容器运行用户组
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      runAsUser: 2000    #容器设置覆盖Pod级别，实际运行用户2000，用户组3000
      allowPrivilegeEscalation: false #禁用权限提升

Docker镜像允许在Dockerfile中指定一个用户来运行容器, 如果指定了runAsUser 将覆盖容器镜像中的用户，如果均未指定任务用户，容器将以root身份运行，推荐在安全上下文指定运行用户，更加灵活。安全上下文设置runAsNonRoot: true Kubernetes可以禁止以root身份运行容器。

2.设置container权能

...
spec:
  containers:
  - name: sec-ctx-4
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      capabilities:
        drop: ["all"]
        add: ["NET_ADMIN", "SYS_TIME"]

具体权能参考https://man7.org/linux/man-pages/man7/capabilities.7.html

二、升级策略

.spec.strategy 策略指定用于用新 Pod 替换旧 Pod 的策略

• .spec.strategy.type==Recreate 重新创建Deployment，在创建新的Pod之前，会先杀死所有旧Pod
• .spec.strategy.type==RollingUpdate 滚动更新的方式更新 Pod(默认策略)

回滚更新参数

• maxUnavailable：和期望ready的副本数比，不可用副本数最大比例（或最大值），这个值越小，越能保证服务稳定，更新越平滑

• maxSurge：和期望ready的副本数比，超过期望副本数最大比例（或最大值），这个值调的越大，副本更新速度越快

...
spec:
   type: RollingUpdate
   rollingUpdate:
       maxSurge: 30%          #默认值25%   不能为0，百分比向上取整
       maxUnavailable: 30%    #默认值25%，不能为0，百分比向下取整

如果replicas=1，且回滚策略未设置默认为25%，那么maxSurge 百分比向上取整为1，maxUnavailable百分比向下取整为0，即创建一个新Pod再停止一个旧Pod

DaemonSet更新策略

最多只能有 DaemonSet 的一个 Pod 运行于每个节点上。

spec.
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1   # 默认策略

三、探针

容器探针主要是有三种：存活探针、就绪探针和启动探针

1.存活探针

kubelet使用存活探针来确定什么时候要重启容器，有助于提高应用的可用性，存活探针可以探测到应用死锁（程序在运行，但是无法服务）

• 存活命令

livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5
      periodSeconds: 5

• 存活HTTP请求接口

livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
        httpHeaders:
        - name: Custom-Header
          value: Awesome
      initialDelaySeconds: 3
      periodSeconds: 3

• TCP存活探针

livenessProbe:
      tcpSocket:
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

• gRPC存活探针

livenessProbe:
      grpc:
        port: 2379
      initialDelaySeconds: 10

• 使用命名端口(HTTP和TCP)

ports:
- name: liveness-port
  containerPort: 8080
  hostPort: 8080

livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port

2.就绪探针

有时候应用启动后暂时无法提供服务，比如启动时需加载大量数据或配置，或者启动后依赖等待外部服务。通过就绪探针，这些未就绪的服务就不会接受Service的流量，保证服务的可用性

3.启动探针

有时候应用启动时间较长，设置启动探针可以保护慢启动容器。可以通过将 failureThreshold * periodSeconds 参数设置为足够长的时间来应对糟糕情况下的启动时间

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10

1.存活探针和就绪探针会禁用直到启动探针成功为止
2.存活探针和就绪探针配置相似，唯一区别livenessProbe 和 readinessProbe 关键字

四、备份&恢复

主要两种方式：ETCD快照备份恢复和Velero工具

ETCD快照备份恢复

主要备份底层ETCD数据,利用ETCD的备份恢复机制，适用于比较严重的集群灾难

备份

cd /etc/etcd/pki #证书目录
etcdctl   --cacert=ca.pem --cert=server.pem --key=server-key.pem     snapshot save  /var/lib/etcd_backup/backup_$(date "+%Y%m%d%H%M%S").db 

恢复

• 1. 暂停控制面板服务kube-apiserver

  mv /etc/kubernetes/manifests /etc/kubernetes/manifests_bak
  

• 2. 停止ETCD服务&删除数据

  systemctl stop etcd     #每个etcd节点执行
  

  mv /var/lib/etcd/default.etcd /var/lib/etcd/default.etcd_bak #利用mv实现删除备份
  

• 3. 恢复ETCD集群数据
     假设机器:172.16.47.16-18， 在机器172.16.47.16执行

   export ETCDCTL_API=3
   etcdctl snapshot restore /var/lib/etcd_backup/backup_20230314112036.db \
   --data-dir="/var/lib/etcd/default.etcd" \
   --name  etcd0 \
   --initial-cluster "etcd0=https://172.16.47.16:2380,etcd1=https://172.16.47.17:2380,etcd2=https://172.16.47.18:2380" \
   --initial-cluster-token etcd-cluster \
   --initial-advertise-peer-urls https://172.16.47.16:2380
  

  chown -R etcd:etcd /var/lib/etcd  # 设置目录权限
  

  三台机器都得执行，注意--name 和 --initial-advertise-peer-urls 的值替换成对应的值

• 4 启动ETCD集群

  systemctl start etcd   #每台etcd执行
  

• 5 恢复控制面板服务kube-apiserver

  mv /etc/kubernetes/manifests_bak /etc/kubernetes/manifests
  

恢复以后Pod 无法使用，需重启Pod

Velero工具