【三】Kubernetes学习心得-Pod 生命期与 Init C 详细介绍

一、器皿生命期

• Init C（复位器皿）仅仅用以 Pod 复位的，不容易一直伴随着 Pod 生命期存有，Init C 在复位进行以后便会身亡。
• 一个 Pod 能够有好几个 Init C，还可以不用 Init C。
• Init C 是先后实行的，第一个实行取得成功后才能够实行下一个 Init C，不可以另外实行。

Main C 撤出后 Pod 生命期便会完毕，Init C 一切正常撤出后 Pod 生命期并不会完毕，可是 Init C 并不是一切正常撤出(回到0)得话，是不容易实行到 Main C 这一步的。
假如 Pod 的 Init 器皿不成功，Kubernetes 会持续的重新启动该 Pod，直至 Init 器皿取得成功截止。
假如 Pod 相匹配的 restartPolicy 为 Never，它不容易重启。

二、Init 器皿

Pod 可以具备好几个器皿，运用运作在器皿里边，可是它也很有可能有一个或好几个在于运用器皿运行的 Init 器皿。

Init 器皿与一般器皿十分类似，除开以下二点：

• Init 器皿一直运作到取得成功进行截止；
• 每一个 Init 器皿都务必在下一个Init器皿运行以前取得成功进行。

Init 器皿应用实例

Init 模版：

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod   # Pod 名字
  labels:  
    app: myapp      # Pod 标识
spec:
  containers:
  - name: myapp-container   # Pod 里边第一个器皿名字
    image: busybox          # 该器皿应用的镜像系统名字
    command: ['sh','-c','echo The app is running! && sleep 3600']
    # 运行命令，輸出一句话完毕后该器皿休眠状态六分钟
  initContainers:         # 对器皿复位
  - name: init-myservice  # 第一个复位器皿名字
    image: busybox        # 复位器皿镜像系统
    command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
    # 分析 myservice ，until 当标准为确实情况下撤出循环系统；
    # 假如分析失败，輸出一句话，休眠状态2s再次循环系统。
  - name: init-mydb   # 第二个复位器皿名字
    image: busybox
    command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']
    # 跟第一个相近，很少追朔。

建立 Pod ：

READY：一共一个必须准备就绪的，如今准备就绪情况为0；
STAUS：一共2个复位器皿，如今一个也没有取得成功；

查询 Init 器皿日志：

分析失败，造成 Init 器皿在持续循环系统分析：

下面建立一个 Service 促使 Init 器皿能够分析取得成功：

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

再度查询 Pod 情况：

在其中第一个 Init 器皿早已实行成功了，因为第二个 Init 器皿或是沒有分析取得成功，因此 Pod 准备就绪情况或是为0。

下面建立 mydb Service ：

kind: Service
apiVersion: v1
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
    port: 80
    targetPort: 9377

这时再度查询 Pod 情况：

仅有2个 Init 器皿复位都成功了，Main C (也就是这儿的 myapp-pod)才会运作取得成功。

独特表明

• 在 Pod 运行全过程中，Init 器皿会按序在 互联网 和 数据信息卷 复位以后运行，每一个器皿务必在下一个器皿运行以前取得成功撤出。

这儿的“互联网”和“数据信息卷”就是指 Pause 器皿，真真正正 Pod 第一个运行的器皿并不是 Init 器皿，只是 Pause 器皿。

• 假如因为运作时或不成功撤出，将造成器皿运行不成功，它会依据 Pod 的 restartPolicy 特定的对策开展再试。殊不知，假如 Pod 的 restartPolicy 设定为 Always，Init 器皿不成功的时候会应用
  RestartPolicy 对策。

• 在全部的 Init 器皿沒有取得成功以前，Pod 将不容易变为 Ready 情况。Init 器皿的端口号将不容易在 Service 中开展集聚。正在初始化中的 Pod 处在 Pending 情况，但应当会将 Initializing 情况设定为 true。

• 假如 Pod 重新启动，全部 Init 器皿务必再次实行。

• 在 Pod 中的每一个 app 和 Init 器皿的名字务必唯一，与一切别的器皿共享资源同一个名字，会在认证时抛出去不正确。

同一组 Init 器皿端口号是能够同样的，由于第一个 Init 器皿运行取得成功后便会撤出，端口号就不容易被占有。

之上有不适当或是讲得错误的地区，期待诸位留言板留言纠正，感谢！
立在巨人的肩膀上！