Linux企业实战之容器（八）——Kubernetes（3）

1 Init容器

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

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

  • 它们总是运行到完成；
  • Init容器不支持Readiness，因为它们必须在Pod就绪之前运行完成 ；
  • 每个Init容器必须运行完成，下一个容器才能够运行。

• 如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。

• Init容器能做什么？

  • Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码；
  • Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低；
  • 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像；
  • Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问；
  • 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。

Init容器实验

步骤一：定义了一个 Init 容器的简单 Pod

vim init.yaml           #编写一个资源清单文件

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: nginx
  initContainers:
  - name: init-myservice
    image: reg.westos.org:5000/busybox
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

步骤二：利用编辑的init.yaml文件创建一个pod

kubectl create  -f  init.yaml  

kubectl describe pod myapp-pod           #查看myapp-pod的具体创建过程

kubectl exec -it myapp-pod -c init-service -- sh    #进入到init-service中
nslookup myservice.default.svc.cluster.local        #解析域名

步骤三：创建一个service解决之前域名无法解析的问题

vim service.yaml

kind: Service
apiVersion: v1
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

kubectl create -f service.yaml               #创建服务

kubectl get pod             #再次查看pod的状态

总结：上面的实验为了说明，在创建pod时，如果pod中的init容器没有完全正常运行，那么其他一般容器则不能正常运行。还有一点就是init容器成功运行后会马上自动释放

2 容器探针

• 探针 是由 kubelet 对容器执行的定期诊断。要执行诊断，kubelet 调用由容器实现的 Handler。有三种类型的处理程序：

  • ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
  • TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
  • HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。

• 每次探测都将获得以下三种结果之一：

  • 成功：容器通过了诊断。
  • 失败：容器未通过诊断。
  • 未知：诊断失败，因此不会采取任何行动。

• Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：

  • livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
  • readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
  • startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。

（1）livenessProbe实验

步骤一：删除集群中之前创建的pod和服务，修改资源清单，添加livenessProbe内容

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image:  nginx
      imagePullPolicy:  IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds:  1
        periodSeconds: 2
        timeoutSeconds: 2


kubectl create -f  pod.yaml

步骤二：修改pod端口，pod会不断的进行重启

kubectl delete -f pod.yaml      #先删除之前创建的正常的pod

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image:  nginx
      imagePullPolicy:  IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds:  1
        periodSeconds: 2
        timeoutSeconds: 2

kubectl create -f  pod.yaml

kubectl  get pod -w

（2）readinessProbe实验

步骤一：删除集群中之前创建的pod和服务，修改资源清单，添加readinessProbe内容

cat pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image:  nginx
      imagePullPolicy:  IfNotPresent
      readinessProbe:
        httpGet:
          path: /test.html
          port: 80
        initialDelaySeconds: 1
        periodSeconds: 3
        timeoutSeconds: 1


kubectl create -f pod.ymal           #创建pod
kubectl get pod                      #查看创建的pod

步骤二：查看创建的nginx这个pod的描述和日志，找寻pod未就绪的原因

kubectl describe pod nginx
kubectl logs nginx                           #查看nginx这个pod的日志

步骤三：以交互式的方式进入到我们创建的nginx这个pod中，在其默认发布目录下创建一个test.html文件

kubectl exec -it nginx -- sh
cd /usr/share/nginx/html\
echo hello > test.html


kubectl get pod

注意：这里的就绪检测是一直进行检测的，伴随pod的整个生命周期

如果我们将上面实验中的test.html文件删除，则就绪检测会再次失败，pod又会处于未就绪。