---

什么是容器？

进程的特点及带来的问题

进程的特点

• 第一，这些进程可以相互看到、相互通信；
• 第二，它们使用的是同一个文件系统，可以对同一个文件进行读写操作；
• 第三，这些进程会使用相同的系统资源。

这样的三个特点会带来什么问题呢？

• 因为这些进程能够相互看到并且进行通信，高级权限的进程可以攻击其他进程；
• 因为它们使用的是同一个文件系统，因此会带来两个问题：这些进程可以对于已有的数据进行增删改查，具有高级权限的进程可能会将其他进程的数据删除掉，破坏掉其他进程的正常运行；此外，进程与进程之间的依赖可能会存在冲突，如此一来就会给运维带来很大的压力；
• 因为这些进程使用的是同一个宿主机的资源，应用之间可能会存在资源抢占的问题，当一个应用需要消耗大量 CPU 和内存资源的时候，就可能会破坏其他应用的运行，导致其他应用无法正常地提供服务。

问题的解决与容器的本质

针对上述的三个问题，如何为进程提供一个独立的运行环境呢？

• 针对不同进程使用同一个文件系统所造成的问题而言，Linux 和 Unix 操作系统可以通过 chroot 系统调用将子目录变成根目录，达到视图级别的隔离；进程在 chroot 的帮助下可以具有独立的文件系统，对于这样的文件系统进行增删改查不会影响到其他进程；

• 因为进程之间相互可见并且可以相互通信，使用 Namespace 技术来实现进程在资源的视图上进行隔离。在 chroot 和 Namespace 的帮助下，进程就能够运行在一个独立的环境下了；

• 但在独立的环境下，进程所使用的还是同一个操作系统的资源，一些进程可能会侵蚀掉整个系统的资源。为了减少进程彼此之间的影响，可以通过 Cgroup 来限制其资源使用率，设置其能够使用的 CPU 以及内存量。

那么，应该如何定义这样的进程集合呢？
其实，容器就是一个视图隔离、资源可限制、独立文件系统的进程集合。所谓“视图隔离”就是能够看到部分进程以及具有独立的主机名等；控制资源使用率则是可以对于内存大小以及 CPU 使用个数等进行限制。容器就是一个进程集合，它将系统的其他资源隔离开来，具有自己独立的资源视图。

什么是Pod？

pod原意是豆荚

在k8s中，pod指的是一组（一个或多个） 容器，类似"进程组"，这些容器共享存储、网络、以及怎样运行这些容器的声明（specification，之后yaml文件的spec）。
Pod 中的内容总是并置（co-located）的并且一同调度，在共享的上下文中运行。Pod 的共享上下文包括一组 Linux 名字空间、控制组（cgroup）和可能一些其他的隔离 方面，即用来隔离 Docker 容器的技术。 在 Pod 的上下文中，每个独立的应用可能会进一步实施隔离。
Kubernetes 假设 Pod 可与其它 Pod 通信，不管它们在哪个主机上。 Kubernetes 给每一个 Pod 分配一个集群私有 IP 地址，所以没必要在 Pod 与 Pod 之间创建连接或将容器的端口映射到主机端口。 这意味着同一个 Pod 内的所有容器能通过 localhost 上的端口互相连通，集群中的所有 Pod 也不需要通过 NAT 转换就能够互相看到。
pause容器

生命周期

Pod 遵循一个预定义的生命周期，起始于 Pending 阶段，如果至少 其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以 失败状态结束而进入 Succeeded 或者 Failed 阶段。

取值	描述
Pending（悬决）	Pod 已被 Kubernetes 系统接受，但有一个或者多个容器尚未创建亦未运行。此阶段包括等待 Pod 被调度的时间和通过网络下载镜像的时间。
Running（运行中）	Pod 已经绑定到了某个节点，Pod 中所有的容器都已被创建。至少有一个容器仍在运行，或者正处于启动或重启状态。
Succeeded（成功）	Pod 中的所有容器都已成功终止，并且不会再重启。
Failed（失败）	Pod 中的所有容器都已终止，并且至少有一个容器是因为失败终止。也就是说，容器以非 0 状态退出或者被系统终止。
Unknown（未知）	因为某些原因无法取得 Pod 的状态。这种情况通常是因为与 Pod 所在主机通信失败。

如果某节点死掉或者与集群中其他节点失联，Kubernetes 会实施一种策略，将失去的节点上运行的所有 Pod 的 phase 设置为 Failed。

探针（probe）

探测机制

所谓的探测机制，就是运行命令

exec

在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。

例如，

echo $?

tcpSocket

对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。 如果远程系统（容器）在打开连接后立即将其关闭，这算作是健康的。
例如，

telnet ip port

httpGet

对容器的 IP 地址上指定端口和路径执行 HTTP GET 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。
例如，

curl -I http://ip:port

grpc(测试中)

使用 gRPC 执行一个远程过程调用。了解一下即可。

探针类型

看 deploy coredns 的yaml

kubectl get deploy coredns -n kube-system -oyaml

后面的为截取的内容

livenessProbe

存活探针，指示容器是否正在运行。如果存活状态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定何时重启。如果容器不提供存活探针， 则默认状态为Success。

livenessProbe:
          failureThreshold: 5
          httpGet:
            path: /health
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 60
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 5

• failureThreshold：失败次数
• initialDelaySeconds：初始化时间
• periodSeconds：检测间隔时间
• successThreshold：成功次数
• timeoutSeconds：超时时间

使用HttpGet的方式，发送数据包来探测。整个流程大致为，发送http数据包，若在5秒内收到200-400状态码，则成功，否则等待10s继续发送，直至失败5次，就认为失败了，容器没有存活。

readinessProbe

就绪探针，指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始化之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪探针，则默认状态为Success。

readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /ready
            port: 8181
            scheme: HTTP
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1

同样使用HttpGet的方式，发送数据包来探测

startupProbe

启动探针，指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其 重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

Init Containers（初始化容器）

创建pod命令执行后，使用get po的时候看到的 Init，用于初始化，一般很小。
• 一直运行，直到完成。
• 每个都必须在下一个启动之前成功完成。

Ephemeral Containers（临时容器）

用于调试、故障排查
临时容器与其他容器的不同之处在于，它们缺少对资源或执行的保证，并且永远不会自动重启， 因此不适用于构建应用程序。 临时容器使用与常规容器相同的 ContainerSpec 节来描述，但许多字段是不兼容和不允许的。
• 临时容器没有端口配置，因此像 ports，livenessProbe，readinessProbe 这样的字段是不允许的。
• Pod 资源分配是不可变的，因此 resources 配置是不允许的。

模版

一个比较全的Pod yaml文件模板

apiVersion: v1 # 必选，API的版本号
kind: Pod       # 必选，类型 这里填Pod
metadata:       # 必选，元数据
  name: nginx   # 必选，符合RFC 1035规范的Pod名称
  namespace: default # 可选，Pod所在的命名空间，不指定默认为default，一般在kubectl中使用-n指定namespace 
  labels:       # 可选，标签选择器，一般用于过滤和区分Pod，可以写多个
    app: nginx
    role: frontend
  annotations:  # 可选，注释列表，可以写多个
    app: nginx
spec:   # 必选，用于定义容器的详细信息
  initContainers: # 可选，初始化容器，在容器启动之前执行的一些初始化操作
 - command:
    - sh
    - -c
    - echo "I am a InitContainer that init some configurations"
    image: busybox
    imagePullPolicy: IfNotPresent # 可选，镜像拉取策略，宿主机有了就不拉取
    name: init-container
  containers:   # 必选，容器列表
 - 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 # 端口协议，默认TCP
    env:    # 可选，环境变量配置列表
    - name: TZ      # 变量名
      value: Asia/Shanghai # 变量的值
    - name: LANG
      value: en_US.utf8
    resources:      # 可选，资源限制和资源请求限制
      limits:       # 最大限制设置
        cpu: 1000m
        memory: 1024Mi
      requests:     # 启动所需的资源
        cpu: 100m
        memory: 512Mi
    startupProbe: # 可选，检测容器内进程是否完成启动。注意三种检查方式同时只能使用一种。
      httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。
            path: /api/successStart # 检查路径
            port: 80
    readinessProbe: # 可选，健康检查。注意三种检查方式同时只能使用一种。
      httpGet:      # httpGet检测方式，生产环境建议使用httpGet实现接口级健康检查，健康检查由应用程序提供。
            path: / # 检查路径
            port: 80        # 监控端口
    livenessProbe:  # 可选，健康检查
      exec:        # 执行容器命令检测方式
            command: 
            - cat
            - /health
      httpGet:       # httpGet检测方式
       path: /_health # 检查路径
       port: 8080
       httpHeaders: # 检查的请求头
       - name: end-user
         value: Jason 
      tcpSocket:    # 端口检测方式
            port: 80
      initialDelaySeconds: 60       # 初始化时间
      timeoutSeconds: 2     # 超时时间
      periodSeconds: 5      # 检测间隔
      successThreshold: 1 # 检查成功为1次表示就绪
      failureThreshold: 2 # 检测失败2次表示未就绪
    lifecycle: # 可选，生命周期
      postStart: # 容器创建完成后执行的指令, 可以是exec httpGet TCPSocket
        exec:
          command:
          - sh
          - -c
          - 'mkdir /data/ '
      preStop: # 容器停止前执行的命令
        httpGet:      
              path: /
              port: 80
        exec:
          command:
          - sh
          - -c
          - sleep 9
  restartPolicy: Always   # 可选，默认为Always，总是拉取。Never不管是否存储都不拉取
  nodeSelector: # 可选，指定Node节点
        region: subnet7
  imagePullSecrets:     # 可选，拉取镜像使用的secret，可以配置多个
 - name: default-dockercfg-86258
  hostNetwork: false    # 可选，是否为主机模式，如是，会占用主机端口
  volumes:      # 共享存储卷列表
 - name: webroot # 名称，与上述对应
     emptyDir: {}    # 挂载目录
        hostPath:              # 挂载本机目录
          path: /etc/hosts

我下载了k8s源代码，可以查看一下PullPolicy

• Always：kubelet pull最新镜像，pull失败，容器就启动失败。
• Nerver：kubelet 不pull镜像，使用本地镜像，没有就失败。
• IfNotPresent：kubelet在镜像没有时就pull，如果本地没有，pull也失败，容器启动失败。

博主喜欢使用第3个

创建

或许你看到前面的很长的yaml已经蒙了，那在这里我们就创建一个简单的仅包含一个nginx容器的Pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx-test
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - name: http
      containerPort: 80

kubectl create -f nginx-test.yaml -n lady-killer9

可以使用 -n 指定命名空间

由于实际使用中基本不会使用原生的Pod，而是使用Deployment等资源，这里博主就不再创建了。建议读者耐心看看模板，然后添加写挂载卷、探针等。

查看

查看部分信息

kubectl get po -n lady-killer9

查看详细信息

kubectl get po -n lady-killer9 -o wide

修改

kubectl replace -f nginx-test.yaml -n lady-killer9

删除

删除pod

kubectl delete -f nginx-test.yaml

强制删除

有时可能遇到这种情况

这时候需要强制删除pod

kubectl delete -f nginx.yaml --force --grace-period=0

参考

CNCF x Alibaba 云原生技术公开课 - 云原生教程-容器基本概念
Pods
Pod 与 Service 的 DNS

更多k8s相关内容，请看文章：k8s学习-思维导图与学习笔记