k8s 中的一些小知识

Pod 不具备自动恢复能力，所以需要 ReplicaSet，ReplicaSet 只在副本数发生变动时有感知，所以需要更上层的 Deployment/StatefulSet

Deployment 的滚动更新是通过 ReplicaSet 实现的

bash 复制代码

[root@k8s-master-01 ~]# k -n <ns> describe deploy <deploy> | grep Replica
Replicas:               2 desired | 2 updated | 2 total | 2 available | 0 unavailable
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   <deploy-name>-65d6674947 (2/2 replicas created)

bash 复制代码

[root@k8s-master-01 ~]# k -n <ns> get replicaset
NAME                             DESIRED   CURRENT   READY   AGE
<deploy-name>-65d6674947       	  2         2         2       2d19h

当发生更新时，会创建新的 replicaset，旧的 replicaset 期望数会变为 0

kubelet 有两个参数可以控制镜像删除的行为，一个是 image-gc-high-threshold，另一个是 image-gc-low-threshold，它们的值默认是 85% 和 80%，这意味着当磁盘使用率达到 85% 的时候自动执行清理，并将磁盘使用率降到 80%。

Service 将一组来自同一个 ReplicaSet 创建的 Pod 组合在一起，并提供 DNS 的访问能力

Service 在集群内拥有唯一的 IP 地址，并且这个 IP 是稳定的（但是删了重新建会获得一个新的 IP）。此外，Service 本身并没有直接提供服务发现的能力，它需要借助 Endpoints 来实现。Endpoints 记录了一组 Pod 的 IP 地址，Service 只需要查看自身所对应的 Endpoints 便能够找到具体的 Pod。

bash 复制代码

[root@k8s-master-01 ~]# k -n <ns> get endpoints
Warning: v1 Endpoints is deprecated in v1.33+; use discovery.k8s.io/v1 EndpointSlice
NAME                  ENDPOINTS                              AGE
<deploy-name>         10.244.128.22:80,10.244.16.128:80      83d

Service 通过 selector 选择关联的 Pod，通过 metadata.name 关联 endpoints

Service 只有在创建后才会分配得到 IP，且删除后重建还会分配新的 IP，所以也需要一个 IP 无关的唯一标识：

bash 复制代码

{$service_name}.{$namespace}.svc.cluster.local

日常可以省略 .svc.cluster.local，同一命名空间下 namespace 也可以省略，即同一命名空间下可以这么访问：

bash 复制代码

{$service_name}

所以在 A Pod 访问其它服务的 B Pod 时的流程其实是：

bash 复制代码

Pod-A -----> service-B -------> Endpoints-B --------> Pod-B

ExternalName 类型的 Service 可以将 Service 和另外一个命名空间的 Service 关联起来

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
	name: backend-service
	namespace: default
spec:
	type: ExternalName
	externalName: backend-service.example.svc.cluster.local

为了统一访问，还可以创建 Service 和 EP 绑定外部服务地址：

yaml 复制代码

apiVersion: v1 
kind: Service 
metadata: 
  name: db 
  namespace: example 
spec: 
  ports: 
    - port: 3306 
      targetPort: 3306 
--- 
apiVersion: v1 
kind: Endpoints 
metadata: 
  name: db 
  namespace: example 
subsets: 
  - addresses: 
      - ip: 10.244.0.1 
      - ip: 10.244.0.2 
      - ip: 10.244.0.3 
    ports: 
      - port: 3306 
        protocol: TCP

通常我们把 Ingress 看作 Service 之上的 Service。 Ingress 对象只用来声明路由策略，并不处理具体的流量转发。要使得 Ingress 生效，还需要额外安装 Ingress-Controller，例如 Ingress-Nginx。

当 kubernetes 决定要驱逐 Pod 的时候，按照未配置资源配额、Request 小于 Limit、Request 等于 Limit 的顺序驱逐，对于一些基础核心组件，例如中间件或者核心服务，可以将 Request 预估为一个较高的合理水平，并且将 Limit 配置为相同的值。HPA 需要安装 Metrics Server 和为工作负载配置资源 Request 工作。

对于启动非常慢的大型应用，随意配置 Readiness 和 Liveness 探针，Pod 将因为探针失败而永远无法启动。修改初始检测时间等字段虽然有效但降低了 kubernetes 检测 Pod 健康状态的频率，这会延迟 kubernetes 感知故障的速度。可以用 StartupProbe 探针来解决这个问题。

Readiness 就绪探针可以让 kubernetes 感知到业务的 Ready 就绪状态，以此来控制什么时候将 Pod 加入到 EndPoints 列表中接收外部流量
Liveness 存活探针当感知到 Pod 不健康时，会重启 Pod
StartupProbe 探针主要用来解决服务启动慢的问题

构建镜像时采用 $" "$ Exec 形式不经过 shell。这种方式更推荐，因为信号传递更可靠，进程 PID 为 1，示例：

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: java-app-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: java-app
  template:
    metadata:
      labels:
        app: java-app
    spec:
      containers:
      - name: java-app
        image: myregistry/myjavaapp:1.0   # 镜像
        command: ["java"]
        args: [
          "-Xmx2g",                      
          "-Xms1g",                      
          "-XX:ParallelGCThreads=4",     
          "-jar", "/app/app.jar",
          "--spring.profiles.active=prod"
        ]