1、 pod生命周期简介

pause容器提供pod最底层的环境
初始化容器必须按照顺序执行，第一个启动成功后退出，第二个才能运行
初始化完成后进入主容器阶段，主容器启动之后怎么判断状态为running
里面有存活探针为liveness，探针判定容器为检测通过，容器就是running
rediness为就绪探针，容器运行成功了，但是比如里面80端口有没有冲突，有没有正常对外发布服务如
2、init初始化容器

官方文档例子
[root@server2 ~]# vim myapp.yaml   
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
  initContainers:     初始化容器
  - name: init-myservice
    image: busybox:latest
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]   表示dns解析默认namespace service服务    cluster.local表示本地集群，如果解析不成功，休眠2s继续解析，直到解析成功为止，do后面是输出的信息
  containers:
    - name: myapp
      image: myapp:v1
      imagePullPolicy: IfNotPresent
[root@server2 ~]# kubectl apply -f myapp.yaml   运行
pod/myapp created
 [root@server2 ~]# kubectl get pod  查看pod
NAME    READY   STATUS     RESTARTS   AGE
myapp   0/1     Init:0/1   0          38s     显示当前有一个初始化容器，还没有启动起来，需要检测myservice服务
[root@server2 ~]# vim myservice.yaml   创建服务
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80     外部端口
    targetPort: 80    容器端口
[root@server2 ~]# kubectl apply -f myservice.yaml   运行
service/myservice created
[root@server2 ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP   3d19h
myservice    ClusterIP   10.103.223.174   <none>        80/TCP    35s     可以发现创建了一个myservice服务
[root@server2 ~]# kubectl  get pod
NAME    READY   STATUS    RESTARTS   AGE
myapp   1/1     Running   0          9m47s     此时初始化容器运行成功后退出，主容器开始运行
[root@server2 ~]# kubectl run demo --image=busybox -it --restart=Never
/ # cat /etc/resolv.conf 
nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local    有解析
options ndots:5
/ # ping myservice
PING myservice (10.103.223.174): 56 data bytes    可以解析到ip地址
3、 探针
 
探针官方文档例子
 通过tcp协议检测80端口： 
[root@server2 ~]# vim myapp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
 # initContainers:
#  - name: init-myservice
#    image: busybox:latest
#    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  containers:
    - name: myapp
      image: myapp:v1
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:    表示tcp协议检测80端口
          port: 8080       专门写一个错的，为了实验效果
        initialDelaySeconds: 2  表示等容器启动之后延迟2s去检测80端口开没开
        periodSeconds: 3   表示检测的间隔为3s
        timeoutSeconds: 1  表示检测的超时
 [root@server2 ~]# kubectl apply -f myapp.yaml  运行
pod/myapp created
[root@server2 ~]# kubectl get pod
NAME    READY   STATUS             RESTARTS      AGE
myapp   0/1     CrashLoopBackOff   6 (64s ago)   4m37s   可以发现存活探针检测不过，连接8080端口失败
 [root@server2 ~]# kubectl delete -f myapp.yaml  删除
[root@server2 ~]# vim myapp.yaml  
pod "myapp" deleted
kind: Pod
metadata:
  name: myapp
spec:
#  initContainers:
#  - name: init-myservice
#    image: busybox:latest
#    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  containers:
    - name: myapp
      image: myapp:v1
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 80   将端口改成80
        initialDelaySeconds: 2
        periodSeconds: 3
        timeoutSeconds: 1
[root@server2 ~]# kubectl apply -f myapp.yaml  运行 
[root@server2 ~]# kubectl get pod   此时就可以运行了 
NAME    READY   STATUS    RESTARTS   AGE
myapp   1/1     Running   0          2m17s
[root@server2 ~]# kubectl delete -f myapp.yaml   删除
pod "myapp" deleted
[root@server2 ~]# vim myapp.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: myapp
spec:
#  initContainers:
#  - name: init-myservice
#    image: busybox:latest
#    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  containers:
    - name: myapp
      image: myapp:v1
      imagePullPolicy: IfNotPresent
      livenessProbe:
        tcpSocket:
          port: 80
        initialDelaySeconds: 2
        periodSeconds: 3
        timeoutSeconds: 2
      readinessProbe:
        httpGet:
          path: /test.html  
          port: 80    表示访问80端口，然后去拿/test.html这个发布页面，有就是就绪了，没有就是没有就绪
        initialDelaySeconds: 2
        periodSeconds: 3
        timeoutSeconds: 2
[root@server2 ~]# kubectl apply -f myapp.yaml  运行
pod/myapp created
 [root@server2 ~]# kubectl get pod  
NAME    READY   STATUS    RESTARTS   AGE   
myapp   0/1     Running   0          21s          可以发现存活探针已经通过，就绪探针没有通过
[root@server2 ~]# kubectl exec -it myapp -- sh  进入容器执行
/ # cd /usr/share/
/usr/share # cd nginx/html/  进入nginx默认发布目录
/usr/share/nginx/html # ls
50x.html    index.html
/usr/share/nginx/html # echo westos > test.html  创建 test.html 发布页面
/usr/share/nginx/html # [root@server2 ~]# kubectl get pod
NAME    READY   STATUS    RESTARTS   AGE
myapp   1/1     Running   0          15m    就绪探针已经通过
   [root@server2 ~]# kubectl get pod -o wide 
NAME    READY（就绪探针看此）   STATUS (存活探针看此）   RESTARTS（重启此数）   AGE    IP            NODE      NOMINATED NODE   READINESS GATES
myapp        0/1                      Running           0               4m4s   10.244.1.19   server3   <none>           <none>                       容器在server3上运行
 [root@server2 ~]# curl 10.244.1.19/test.html
westos
				livenessProbe: 是指容器是否正在运行。如果存活性探测失败，则kubelete会杀死容器，并且容器受重启策略的影响。如果容器不提供存活性探针，则默认状态为Success。
[root@k8s-master01 k8s-test]# cat liveness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: kone.com/libr
				readinessProbe: 指示容器是否准备好服务请求。如果就绪探针失败，端点控制器将从Pod匹配的所有Service的端点中删除该pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认状态为Success。
检测nginx容器的/usr/share/nginx/html/kone.html是否存在
[root@k8s-master01 k8s-test]# cat readiness.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace
图解 K8S（01）：基于ubuntu 部署最新版 k8s 集群
图解 K8S（02）：认识 K8S 中的资源对象
图解 K8S（03）：从 Pause 容器理解 Pod 的本质
图解 K8S（04）：吃透 Pod 中的第三类容器 – init 容器
以下是本篇正文
从上一篇文章，我们已经知道了一个 Pod 至少会有两种容器， pause 容器和 应用容器。
注意我的表述是 至少，这其实已经在暗示 Pod 里还存在其他类型的容器，这就是我们本篇文章的主角 – init 容器。
知乎大神：https://zhuanlan.zhihu.com/p/104637613
kubernetes中，用pause容器来作为一个pod中所有容器的父容器。这个pause容器有两个核心的功能，
第一，它提供整个pod的Linux命名空间的基础。
第二，启用PID命名空间，它在每个pod中都作为PID为1进程，并回收僵尸进程。
Order of readiness probe and liveness probe
LivenessProbe should start after ReadinessProbe Succeeded if ReadinessProbe is specified
issue 27114
LivenessProbe should start after ReadinessProbe Succeeded if ReadinessProbe is 
				K8s系列之：Init Container初始化容器一、认识Init container二、Init Container应用实例三、init container与应用容器的区别四、相关拓展知识cgroups和Qos
在很多应用场景中，应用在启动之前都需要进行如下初始化操作。
等待其他关联组件正确运行（例如数据库或某个后台服务）
基于环境变量或配置模版生成配置文件
从远程数据库获取本地所需配置，或者将自身注册到某个中央数据库中
下载相关依赖包，或者对系统进行一些预配置操作
一、认识Init contain
				最近因为查找问题，看了一些k8s的liveness和readiness配置，这两种都是k8s探针用于健康检测的，是k8s很重要的一个特性，在此记录一下，留作备忘。
健康检查（health check）是用于检测应用实例是否正常工作，对应用状态的监控，保障业务高可用的一种机制。
k8s健康检测主要分为以下三种:
存活性探测（Liveness probes） :主要是探测应用是否还活着。如果检测到应用没有存活就杀掉当前pod并重启。
就绪性探测（Readiness probes）:只要是探测应用是否.
				一个 Pod 中可以有多个 container，也可以有多个 init container，init container 会在应用启动之前启动，并且如果有多个应用会依次启动，只有一个运行成功了，才会启动下一个，所有 init container 都运行结束了，应用才会启动，因此，我们可以借助 init container 来检查应用的依赖（如：db/redis/es...）是否已经可用。
Ini...
				k8s是目前最流行的容器编排平台，而k8s初始化master是k8s集群创建的第一步。k8s初始化master包括以下几个步骤：
1. 安装Docker：在k8s中，容器是最基本的执行单元，Docker是k8s容器的运行环境。因此，需要先安装Docker。
2. 安装kubeadm：kubeadm是k8s官方提供的工具，用于快速部署k8s集群。需要提前下载安装kubeadm。
3. 初始化master：运行kubeadm init命令，此命令会自动下载k8s各组件并启动，包括etcd、kube-apiserver、kube-controller-manager和kube-scheduler等。
4. 安装网络插件：由于k8s容器之间需要通信，需要安装网络插件。常用的网络插件有Calico、Flannel、Weave等，选择一种合适的网络插件进行安装。
以上就是k8s初始化master的基本步骤。需要注意的是，在初始化过程中可能会遇到一些问题，如网络配置不正确、节点无法连接等等。因此，需要对k8s的基础知识有一定的了解，才能顺利完成k8s初始化master的操作。
1、 pod生命周期简介

2、init初始化容器

3、 探针

3、探针
