一 kubernetes 基础

Kubernetes是谷歌以Borg为前身，基于谷歌15年生产环境经验的基础上开源的一个项目，Kubernetes致力于提供跨主机集群的自动部署、扩展、高可用以及运行应用程序容器的平台。

二 Master 节点

• kube-APIServer：集群的控制中枢，各个模块之间信息交互都需要经过Kube-APIServer，同时它也是集群管理、资源配置、整个集群安全机制的入口。
• kube-controller-manager：集群的状态管理器，保证Pod或其他资源达到期望值，也是需要和APIServer进行通信，在需要的时候创建、更新或删除它所管理的资源。
• kube-scheduler：集群的调度中心，它会根据指定的一系列条件，选择一个或一批最佳的节点，然后部署我们的Pod。
• etcd：键值数据库，报错一些集群的信息，一般生产环境中建议部署三个以上节点（奇数个。生产环境建议用SSD存储以提高性能）。

三 Node 节点

• Kubelet：负责监听节点上Pod的状态，同时负责上报节点和节点上面Pod的状态，负责与Master节点通信，并管理节点上面的Pod。
• Kube-proxy：负责Pod之间的通信和负载均衡，将指定的流量分发到后端正确的机器上。查看Kube-proxy工作模式：curl 127.0.0.1:10249/proxyMode，Ipvs：监听Master节点增加和删除service以及endpoint的消息，调用Netlink接口创建相应的IPVS规则。通过IPVS规则，将流量转发至相应的Pod上。
• Calico：符合CNI标准的网络插件，给每个Pod生成一个唯一的IP地址，并且把每个节点当做一个路由器。
• CoreDNS：用于Kubernetes集群内部Service的解析，可以让Pod把Service名称解析成IP地址，然后通过Service的IP地址进行连接到对应的应用上。
• Docker：容器引擎，负责对容器的管理。（或者用containerd）

四 什么是pod

Pod可简单地理解为是一组、一个或多个容器，具有共享存储/网络及如何运行容器的规范。Pad包含一个或多个相对紧密耦合的应用程序容器，处于同一个Pod中的容器共享同样的存储空间（Volume，卷或存储卷）、IP地址和Port端口，容器之间使用localhost:port相互访问。根据Docker的构造，Pod可被建模为一组具有共享命令空间、卷、IP地址和Port端口的Docker容器。
Pod包含的容器最好是一个容器只运行一个进程。每个Pod包含一个pause容器，pause容器是Pod的父容器，它主要负责僵尸进程的回收管理。
Kubernetes为每个Pod都分配一个唯一的IP地址，这样就可以保证应用程序使用同一端口，避免了发生冲突的问题。

nginx pod

apiVersion: v1 # 必选，API的版本号
kind: Pod       # 必选，类型Pod
metadata:       # 必选，元数据name: nginx   # 必选，符合RFC 1035规范的Pod名称namespace: app # 可选，Pod所在的命名空间，不指定默认为default，可以使用-n 指定namespace labels:       # 可选，标签选择器，一般用于过滤和区分Podapp: nginxrole: frontend # 可以写多个annotations:  # 可选，注释列表，可以写多个app: nginx
spec:   # 必选，用于定义容器的详细信息initContainers: # 初始化容器，在容器启动之前执行的一些初始化操作- command:- sh- -c- echo "I am InitContainer for init some configuration"image: busyboximagePullPolicy: IfNotPresentname: init-containercontainers:   # 必选，容器列表- name: nginx # 必选，符合RFC 1035规范的容器名称image: nginx:latest    # 必选，容器所用的镜像的地址imagePullPolicy: Always     # 可选，镜像拉取策略command: # 可选，容器启动执行的命令- nginx - -g- "daemon off;"workingDir: /usr/share/nginx/html       # 可选，容器的工作目录volumeMounts:   # 可选，存储卷配置，可以配置多个- name: webroot # 存储卷名称mountPath: /usr/share/nginx/html # 挂载目录readOnly: true        # 只读ports:  # 可选，容器需要暴露的端口号列表- name: http    # 端口名称containerPort: 80     # 端口号protocol: TCP # 端口协议，默认TCPenv:    # 可选，环境变量配置列表- name: TZ      # 变量名value: Asia/Shanghai # 变量的值- name: LANGvalue: en_US.utf8resources:      # 可选，资源限制和资源请求限制limits:       # 最大限制设置cpu: 1000mmemory: 1024Mirequests:     # 启动所需的资源cpu: 1000mmemory: 512MistartupProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。path: /api/successStart # 检查路径port: 80readinessProbe: # 可选，健康检查。注意三种检查方式同时只能使用一种。httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。path: / # 检查路径port: 80        # 监控端口livenessProbe:  # 可选，健康检查#exec:        # 执行容器命令检测方式#command: #- cat#- /healthhttpGet:       # httpGet检测方式path: /_health # 检查路径port: 8080httpHeaders: # 检查的请求头- name: end-uservalue: Jason tcpSocket:    # 端口检测方式port: 80initialDelaySeconds: 60       # 初始化时间timeoutSeconds: 2     # 超时时间periodSeconds: 5      # 检测间隔successThreshold: 1 # 检查成功为2次表示就绪failureThreshold: 2 # 检测失败1次表示未就绪lifecycle:postStart: # 容器创建完成后执行的指令, 可以是exec httpGet TCPSocketexec:command:- sh- -c- 'mkdir /data/ 'preStop:httpGet:      path: /port: 80exec:command:- sh- -c- sleep 9restartPolicy: Always   # 可选，容器重启策略，默认为AlwaysnodeSelector: # 可选，指定Node节点region: subnet7imagePullSecrets:     # 可选，拉取镜像使用的secret，可以配置多个- name: default-dockercfg-86258hostNetwork: false    # 可选，是否为主机模式，如是，会占用主机端口volumes:      # 共享存储卷列表- name: webroot # 名称，与上述对应emptyDir: {}    # 挂载目录hostPath:              # 挂载本机目录path: /etc/hosts

五 Pod 生命周期

Pod 自身不具有自愈能力。如果 Pod 被调度到某节点而该节点之后失效， Pod 会被删除；类似地，Pod 无法在因节点资源耗尽或者节点维护而被驱逐期间继续存活。 Kubernetes 使用一种高级抽象来管理这些相对而言可随时丢弃的 Pod 实例， 称作控制器。

pod生命周期分类：

• Pending（等待） Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
• Running（运行中） Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
• Succeeded（成功） Pod 中的所有容器都已成功终止，并且不会再重启。
• Failed（失败） Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
• Unknown（未知） 因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。
• Terminated（已终止）Pod 处于 Terminated 状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。 如果你使用 kubectl 来查询包含 Terminated 状态的容器的 Pod 时， 你会看到容器进入此状态的原因、退出代码以及容器执行期间的起止时间。（如果容器配置了 preStop 回调，则该回调会在容器进入 Terminated 状态之前执行）

六 容器重启策略

Pod 的 spec 中包含一个 restartPolicy 字段，其可能取值包括 Always、OnFailure 和 Never。默认值是 Always。

• Always：当容器终止退出后，总是重启容器，默认策略
• OnFailure：当容器异常退出（退出状态码非0）时，重启容器
• Never：当容器终止退出，从不重启容器。

当 kubelet 根据配置的重启策略处理容器重启时，仅适用于同一 Pod 内替换容器并在同一节点上运行的重启。当 Pod 中的容器退出时，kubelet 会按指数回退方式计算重启的延迟（10s、20s、40s、…），其最长延迟为 5 分钟。 一旦某容器执行了 10 分钟并且没有出现问题，kubelet 对该容器的重启回退计时器执行重置操作。 Sidecar 容器和 Pod 生命周期中解释了 init containers 在指定 restartpolicy 字段时的行为。

七 Init 容器

每个 Pod 中可以包含多个容器， 应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。

Init 容器与普通的容器非常像，除了如下两点：

• 它们总是运行到完成。
• 每个都必须在下一个启动之前成功完成。

如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy 值为 “Never”，并且 Pod 的 Init 容器失败， 则 Kubernetes 会将整个 Pod 状态设置为失败。

Init 容易与主应用容器的区别

• 在 Pod 初始化期间完成运行的容器，即先运行init容器结束后运行应用容器。
• Init 容器支持应用容器的全部字段和特性，包括资源限制、 数据卷和安全设置。
• 常规的 Init 容器（即不包括边车容器）不支持 lifecycle、livenessProbe、readinessProbe 或 startupProbe 字段。
• 如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

使用 Init 容器

init 容器特点：（总结一下就是为了初始化应用容器的一个方式，优化应用容器的体积。）

• Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。

• 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。

• 与同一 Pod 中的多个应用容器相比，Init 容器能以不同的文件系统视图运行。因此，Init 容器可以被赋予访问应用容器不能访问的 Secret 的权限。

• 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

• Init 容器可以安全地运行实用程序或自定义代码，而在其他方式下运行这些实用程序或自定义代码可能会降低应用容器镜像的安全性。 通过将不必要的工具分开，你可以限制应用容器镜像的被攻击范围。

示例：
下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个 启动 init-myservice， 第二个启动 init-mydb。这两个init容器启动完成以后，Pod 将启动 spec 节中的 myapp-container 应用容器。

apiVersion: v1
kind: Pod
metadata:name: myapp-podlabels:app.kubernetes.io/name: MyApp
spec:containers:- name: myapp-containerimage: busybox:1.28command: ['sh', '-c', 'echo The app is running! && sleep 3600']initContainers:- name: init-myserviceimage: busybox:1.28command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]- name: init-mydbimage: busybox:1.28command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

八 边车容器

边车容器是与主应用容器在同一个 Pod 中运行的辅助容器。 这些容器通过提供额外的服务或功能（如日志记录、监控、安全性或数据同步）来增强或扩展主应用容器的功能， 而无需直接修改主应用代码。

与主应用容器的区别

• 边车容器与同一 Pod 中的常规容器并行运行。不过边车容器不执行主应用逻辑，而是为主应用提供支持功能。

• 边车容器具有独立的生命周期。它们可以独立于常规容器启动、停止和重启。 这意味着你可以更新、扩展或维护边车容器，而不影响主应用

• 边车容器与主容器共享相同的网络和存储命名空间。这种共存使它们能够紧密交互并共享资源。

与init 容器的区别

• 边车容器与主容器并行工作，扩展其功能并提供附加服务，Init 容器不会持续与主容器一起运行。
• 边车容器与主应用容器同时运行。它们在整个 Pod 的生命周期中都处于活动状态，并且可以独立于主容器启动和停止。 与 Init 容器不同， 边车容器支持所有探针来控制其生命周期。
• 这些边车容器可以直接与主应用容器进行交互，共享相同的网络命名空间、文件系统和环境变量。 所有这些容器紧密合作，提供额外的功能。
• 书写格式上面有带呢区别，缩紧不一样。

示例：

apiVersion: apps/v1
kind: Deployment
metadata:name: myapplabels:app: myapp
spec:replicas: 1selector:matchLabels:app: myapptemplate:metadata:labels:app: myappspec:containers:- name: myappimage: alpine:latestcommand: ['sh', '-c', 'echo "logging" > /opt/logs.txt']volumeMounts:- name: datamountPath: /optinitContainers:- name: logshipperimage: alpine:latestrestartPolicy: Alwayscommand: ['sh', '-c', 'tail /opt/logs.txt']volumeMounts:- name: datamountPath: /optvolumes:- name: dataemptyDir: {}

九 Pod 探针

• StartupProbe：k8s1.16版本后新加的探测方式，用于判断容器内应用程序是否已经启动。如果配置了startupProbe，就会先禁止其他的探测，直到它成功为止，成功后将不在进行探测。
• LivenessProbe：用于探测容器是否运行，如果探测失败，kubelet会根据配置的重启策略进行相应的处理。若没有配置该探针，默认就是success。
• ReadinessProbe：一般用于探测容器内的程序是否健康，它的返回值如果为success，那么久代表这个容器已经完成启动，并且程序已经是可以接受流量的状态。

探针检测方式

• ExecAction：在容器内执行一个命令，如果返回值为0，则认为容器健康。
• TCPSocketAction：通过TCP连接检查容器内的端口是否是通的，如果是通的就认为容器健康。
• HTTPGetAction：通过应用程序暴露的API地址来检查程序是否是正常的，如果状态码为200~400之间，则认为容器健康。

ExecAction 探测举例：

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-exec
spec:containers:- name: livenessimage: registry.k8s.io/busyboxargs:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5

TCPSocketAction 举例：

apiVersion: v1
kind: Pod
metadata:name: goproxylabels:app: goproxy
spec:containers:- name: goproxyimage: registry.k8s.io/goproxy:0.1ports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 10livenessProbe:tcpSocket:port: 8080initialDelaySeconds: 15periodSeconds: 20

HTTPGetAction 举例：

apiVersion: v1
kind: Pod
metadata:labels:test: livenessname: liveness-http
spec:containers:- name: livenessimage: registry.k8s.io/livenessargs:- /serverlivenessProbe:httpGet:path: /healthzport: 8080httpHeaders:- name: Custom-Headervalue: AwesomeinitialDelaySeconds: 3periodSeconds: 3

探针参数配置

initialDelaySeconds: 60       # 初始化时间
timeoutSeconds: 2             # 超时时间
periodSeconds: 5              # 检测间隔
successThreshold: 1           # 检查成功为1次表示就绪
failureThreshold: 2           # 检测失败2次表示未就绪

十 定义 postStart 和 preStop 处理函数

创建一个包含一个容器的 Pod，该容器为 postStart 和 preStop 事件提供对应的处理函数。

在下面的配置文件中，你可以看到 postStart 命令在容器的 /usr/share 目录下写入文件 message。 命令 preStop 负责优雅地终止 nginx 服务。当因为失效而导致容器终止时，这一处理方式很有用。

apiVersion: v1
kind: Pod
metadata:name: lifecycle-demo
spec:containers:- name: lifecycle-demo-containerimage: nginxlifecycle:postStart:exec:command: ["/bin/sh", "-c", "echo Hello from the postStart handler > /usr/share/message"]preStop:exec:command: ["/bin/sh","-c","nginx -s quit; while killall -0 nginx; do sleep 1; done"]