k8s-pod

介绍

1、pod 是k8s 中的最小部署单元，一个pod 可以运行多个容器，也可以运行一个容器。

2、pod 相比于容器，通过pod把容器包装到其中，通过k8s管理，可以实现负载均衡、高可用的特性（pod 中容器进程挂掉，应用程序异常主动通知k8s，通过健康检查检测程序异常,集群节点挂掉等都可以重新创建pod或者迁移pod，而容器不具备上述特性。

pod 存在的意义

Pod为亲密性应用而存在。

亲密性应用场景：

• 两个应用之间发生文件交互

• 两个应用需要通过127.0.0.1或者socket通信

• 两个应用需要发生频繁的调用

同一个 Pod 多容器的弊端

如果一个pod  部署多个应用，或者多个容器，那么当需要扩容、重启pod 的时候Pod 中的应用都是同步执行的，这样不灵活，也浪费资源。 通过命令当前终端方式查看Pod 日志多个容器的应用日志混合在一起输出，不方便辨别。

POD 隔离与共享

由于不能将多个进程聚集在一个单独的容器中， 我们需要另 一种更高级的结构来将容器绑定在一起，并将它们作为一个单元进行管理，这就是 pod 背后的根本原理。

在包含容器的 pod 下，我们可以同时运行一些密切相关的进程，并为它们提供（几乎） 相同的环境， 此时这些进程就好像全部运行于单个容器中一样， 同时又保待着
一定的隔离。 这样一来， 我们便能全面地利用容器所提供的特性， 同时对这些进程来说它们就像运行在一起一样， 实现两全其美。

同一 pod 中容器之间的部分隔离

我们已经了解到容器之间彼此是完全隔离的， 但此时我们期望的是隔离容器组， 而不是单个容器， 并让每个容器组内的容器共享一些资源， 而不是全部（换句话说， 没有完全隔离）。 Kubemetes 通过配置 Docker 来让一个 pod 内的所有容器共享相同的 Linux 命名空间， 而不是每个容器都有自己的一组命名空间。
由千一个 pod 中的所有容器都在相同的 network 和 UTS 命名空间下运行（在这里我们讨论的是 Linux 命名空间）， 所以它们都共享相同的主机名和网络接口。 同样
地， 这些容器也都在相同的 IPC 命名空间下运行， 因此能够通过 IPC 进行通信。 在最新的 Kubernetes 和 Docker 版本中， 它们也能够共享相同的 PID 命名空间， 但是
该特征默认是未激活的。注意 当同一个 pod 中的容器使用单独的 PID 命名空间时， 在容器中执行 ps  aux 就只会看到容器自己的进程。
但当涉及文件系统时， 情况就有所不同。 由于大多数容器的文件系统来自容器镜像， 因此默认情况下， 每个容器的文件系统与其他容器完全隔离。 但我们可以使
用名为 Volume 的 Kubernetes 资源来共享文件目录

容器如何共享相同的IP和端口空间

这里需强调的一 点是， 由于一个 pod 中的容器运行于相同的 Network 命名空间中， 因此它们共享相同的 IP 地址和端口空间。 这意味着在同一 pod 中的容器运行的
多个进程需要注意不能绑定到相同的端口号， 否则会导致端口冲突， 但这只涉及同-pod 中的容器。 由千每个 pod 都有独立的端口空间， 对于不同 pod 中的容器来说
则永远不会遇到端口冲突。 此外， 一个 pod 中的所有容器也都具有相同的 loopback网络接口， 因此容器可以通过 localhost 与同一 pod 中的其他容器进行通信。

共享网络的实现

docker 容器都是独立的命名空间，但是相同的pod  中的容器是同一网络环境。这个是由于在创建pod 的时候会自动生成一个infrastructure Container 的容器，此容器生成pod 中的网络环境，其他pod 加入它构建的网络环境，处于同一个命名空间，同一pod 中的所有容器的IP 都是相同的。

注：还有一个init 初始化容器，需要自定义创建，此容器会在业务容器创建之前创建。

共享存储

通过挂载node 节点相同的数据盘实现共享存储

 

Pod 的健康保证

通过kubelet 管理

kubelet 是运行在每个node 节点的进程，它负载监控自己节点上的Pod 的情况，并且上报相关信息，出现异常会重启相关容器。

1、容器的主进程崩溃， Kubelet 将重启容器

2、容器内的应用程序挂掉，kubelet 就会重启应用程序

3、通过健康检查（存活探针）检查应用，如果异常则重新启动容器

通过 ReplicationController

一个集群节点挂掉了，那么节点上的kubelet和所有pod都会挂掉，此时通过副本控制器可以在其他节点重新创建pod 

Pod重启原因查看

通过kubectl  describe pod  -n  namespace  查看 Last state下的退出状态码和 Events 等信息。

关于退出代码理解

例如退出代码为137, 这有特殊的含义-----表示该进程由外部信号终止。数字137是两个数字的总和：128+x, 其中x是终止进程的信号编号。在这个例子中，x等于9, 这是SIGKILL的信号编号，意味着这个进程被强行终止

Pod 存活探针

Kubemetes 可以通过存活探针 (liveness probe) 检查容器是否还在运行。 可以为 pod 中的每个容器单独指定存活探针。 如果探测失败， Kubemetes 将定期执行探针并重新启动容器。

三种探测容器的机制

1、HTTPGET探针对容器的 IP 地址（你指定的端口和路径）执行 HTTP GET 请求，根据状态码决定是否重启容器。

2、TCP套接字探针尝试与容器指定端口建立TCP连接。如果连接成功建立，则探测成功。否则，容器重新启动。

3、Exec探针在容器内执行任意命令，并检查命令的退出状态码。如果状态码是 0, 则探测成功。所有其他状态码都被认为失败。

存活探针的附加属性

除了明确指定的存活探针选项，还可以看到其他属性，例如delay(延迟）、超时timeout(超时）、period(周期）等。delay=0s部分显示在容器启动后立即开始探测。超时timeout仅设置为1秒，因此容器必须在1秒内进行响应， 不然这次探测记作失败。每10秒探测一次容器(period=lOs), 并在探测连续三次失败(# failure=3)后重启容器。定义探针时可以自定义这些附加参数。

 

配置示例（设置初始延迟，将initialDelaySeconds属性添加到存活探针的配置中）

livenessProbe: 
  httpGet: 
    path: /
    port： 8080
  initialDelaySeconds: 15　　　　　　　　　　#Kubernetes 会在第—次探测前等待15秒

View Code