9pod常见状态及故障原因及pod设计模式和类型

Posted 2023-03-07

pod常见状态及故障原因

1、Unschedulable: #Pod不能被调度，kube-scheduler没有匹配到合适的node节点
2、PodScheduled: #Pod正处于调度中，在kube-scheduler刚开始调度时候，还没有将pod分配到指定的node，在筛选出合适的节点后就会更新etcd数据，将pod分配到指定的node
3、Pending： #正在创建Pod但是Pod中的容器还没有全部被创建完成=[处于此状态的Pod应该检查Pod依赖的存储是否有权限挂载等。]
4、Failed： #Pod中有容器启动失败而导致pod工作异常。
5、Unknown： #由于某种原因无法获得Pod的当前状态，通常是由于与pod所在的node节点通信错误。
6、Initialized： #所有pod中的初始化容器已经完成了
7、ImagePullBackOff： #Pod所在的node节点下载镜像失败
8、Running： #Pod内部的容器已经被创建并且启动。
9、Ready： #表示pod中的容器已经可以提供访问服务
10、Error： # pod启动过程中发生错误
11、NodeLost： #Pod所在节点失联
12、Waiting： #Pod等待启动
13、Terminal： #Pod正在被销毁
14、CrashLoopGBackOff: #pod,但是kubelet正在将它重启
15、InvalidImageName： #node节点无法解析镜像名称导致的镜像无法下载
16、ImageInspectError: #无法校验镜像，镜像不完整导致
17、ErrImageNeverPull： #策略禁止拉取镜像，镜像中心权限是私有等
18、RegistryUnavailable： #镜像服务器不可用，网络原因或harbor宕机
19、ErrImagePull：#镜像拉取出错，超时或下载被强制终止
20、CreateContainerConfigError： #不能创建kubelet使用的容器配置
21、CreateContainerError： #创建容器失败
22、RunContainerError：#pod运行失败，容器中没有初始化PID为1的守护进程等
23、ContainersNotInitialized: #pod没有初始化完毕
24、ContainerNotReady： #pod没有准备完毕
25、ContainerCreating：#pod正在创建中
26、PodInitializing： #pod正在初始化中、
27、DockerDaemonNotReady：#node节点docker服务没有启动
28、NetworkPluginNotReady: #网络插件没有启动

Pod设计模式

基于容器的分布式系统中常用的3类设计模式

◼ 单容器模式：单一容器形式运行的应用
◼ 单节点模式：由强耦合的多个容器协同共生
◼ 多节点模式：基于特定部署单元（Pod）实现分布式算法

单节点多容器模式

◼ 一种跨容器的设计模式
◼ 目的是在单个节点之上同时运行多个共生关系的容器，因而容器管理系统需要由将它们作为一个原子单位进
行统一调度
◼ Pod概念就是这个设计模式的实现之一

单节点多容器模式的常见实现

Sidecar模式
◆Pod中的应用由主应用程序（通常是基于HTTP协议的应用程序）以及一个Sidecar容器组成
◆辅助容器用于为主容器提供辅助服务以增强主容器的功能，是主应用程序是必不可少的一部分，但却未必非得运行
为应用的一部分

Ambassador模式
◆Pod中的应用由主应用程序和一个Ambassador容器组成
◆辅助容器代表主容器发送网络请求至外部环境中，因此可以将其视作主容器应用的“大使”
◆应用场景：云原生应用程序需要诸如断路、路由、计量和监视等功能，但更新已有的应用程序或现有代码库以添加这些功能可能很困难，甚至难以实现，进程外代理便成了一种有效的解决方案

Adapter模式
◆Pod中的应用由主应用程序和一个Adapter容器组成
◆Adapter容器为主应用程序提供一致的接口，实现了模块重用，支持标准化和规范化主容器应用程序的输出以便于外部服务进行聚合

Init Container模式
◆一个Pod中可以同时定义多个Init容器
◆Init容器负责以不同于主容器的生命周期来完成那些必要的初始化任务，包括在文件系统上设置必要的特殊权限、
数据库模式设置或为主应用程序提供初始数据等，但这些初始化逻辑无法包含在应用程序的镜像文件中，或者出于
安全原因，应用程序镜像没有执行初始化活动的权限等等
◆Init容器需要串行运行，且在所有Init容器均正常终止后，才能运行主容器

单节点多容器的Sidecar模式范例

[root@K8s-master01 chapter4]#cat sidecar-container-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: sidecar-container-demo
  namespace: default
spec:
  containers:
  - name: proxy                                             #主容器的代理容器
    image: envoyproxy/envoy-alpine:v1.14.1
  - name: demo
    image: ikubernetes/demoapp:v1.0                         #主容器
    imagePullPolicy: IfNotPresent
    env:
    - name: HOST
      value: "127.0.0.1"
    - name: PORT
      value: "8080"
      
创建pod
[root@K8s-master01 chapter4]#kubectl apply -f sidecar-container-demo.yaml 
pod/sidecar-container-demo created
查看pod
[root@K8s-master01 chapter4]#kubectl get pods
NAME                                READY   STATUS              RESTARTS          AGE
sidecar-container-demo              0/2     ContainerCreating   0                 28s
对应的容器数量变成了2

Init Container模式（初始化容器必须定义在专用的字段当中 spec下的 initContainers） 范例

其中多个容器只能串行运行，只有initContainers中的所有容器都运行完了，containers中的容器才会并行运行

initContainers中容器加了权限，设定了iptables规则，运行退出之后，以一个普通用户容器的身份来运行demoapp，即便他自己没有监听8080端口，但是由于跳转规则的实现，往8080发请求，也可以得到结果

[root@K8s-master01 chapter4]#cat init-container-demo.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: init-container-demo
  namespace: default
spec:
  initContainers:
  - name: iptables-init
    image: ikubernetes/admin-box:latest
    imagePullPolicy: IfNotPresent
    command: [/bin/sh,-c]
    args: [iptables -t nat -A PREROUTING -p tcp --dport 8080 -j REDIRECT --to-port 80]
    securityContext:
      capabilities:
        add:
        - NET_ADMIN
  containers:
  - name: demo
    image: ikubernetes/demoapp:v1.0
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80

创建pod并查看
[root@K8s-master01 chapter4]#kubectl apply -f init-container-demo.yaml 
pod/init-container-demo created
[root@K8s-master01 chapter4]#kubectl get pods
NAME                                READY   STATUS     RESTARTS          AGE
init-container-demo                 0/1     Init:0/1   0                 3s

其中1表示有几个初始化容器     0表示有几个完成了

完成之后变成Running状态
init-container-demo                 1/1     Running   0                 100s

Pod类型：

API Server管理的Pod
            (1) 自主式Pod
            (2) 由某个工作负载型控制器控制的Pod
kubelet直接管理：静态Pod，并非从API Server加载，而是自行通过某个资源配置文件加载的Pod；
kubeadm部署的集群中，控制平面中的几个组件的Pod，均为静态Pod，其配置文件位于/etc/kubernetes/manifests/
        etcd 
        kube-apiserver
        kube-scheduler 
        kube-controller-manager

        kubelet通过自动加载某个目录中的资源配置文件启动的Pod，还会持续监视该目录下的配置文件中定义的资源的变动