Pod
Pods是一种容器
我们已经看到,我们可以将命名空间和cgroups与多个线程结合起来,而这正是Kubernetes Pods的本质。Pods让你可以指定想要运行的容器,而Kubernetes自动地建立相应的命名空间和cgroups。实际上还要复杂一些,因为Kubernets并不使用Docker网络(Kubernetes使用CNI,Container Network Interface,容器网络接口),但是本质是类似的。
只要我们将容器设置成这种模式,每个进程会“感觉”它运行在同一台机器上。这些容器可以在本机互相通信,也可以共享存储卷(volume)。他们之间甚至可以使用IPC或者互相发送HUP或者TERM这种信号(需要在Kubernetes 1.7,以及Docker>=1.3环境共享PID命名空间)。
什么是Pod
- Pod是Kubernetes创建或部署的最小/最简单的基本单位,一个Pod代表集群上正在运行的一个进程。Pod实际上是容器的集合,在k8s中对运行容器的要求为:容器的主程序需要一直在前台运行,而不是后台运行。
工作方式
- Pod中运行一个容器
- “one-container-per-Pod”模式是Kubernetes最常见的用法; 在这种情况下,你可以将Pod视为单个封装的容器,但是Kubernetes是直接管理Pod而不是容器。
- Pods中运行多个需要一起工作的容器
- Pod可以封装紧密耦合的应用,它们需要由多个容器组成,它们之间能够共享资源,这些容器可以形成一个单一的内部service单位,一个容器共享文件,另一个“sidecar”容器来更新这些文件。Pod将这些容器的存储资源作为一个实体来管理。ernetes中的Pod使用可分两种主要方式。
两种类型
- 自由主Pod
- 控制器管理的Pod
Pods如何管理多个容器
- Pods的设计可用于支持多进程的协同工作(作为容器),形成一个cohesive的Service单位。Pod中的容器在集群中Node上被自动分配,容器之间可以共享资源、网络和相互依赖关系,并同时被调度使用。
- 在单个Pod中共同管理多个容器是一个相对高级的用法,应该只有在容器紧密耦合的特殊实例中使用此模式。例如,有一个容器被用作WEB服务器,用于共享volume,以及一个单独“sidecar”容器需要从远程获取资源来更新这些文件。
Pods提供两种共享资源:网络和存储。
l 网络
- 每个Pod被分配一个独立的IP地址,Pod中的每个容器共享网络命名空间,包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。当Pod中的容器与Pod 外部通信时,他们必须协调如何使用共享网络资源(如端口)。
l 存储
- Pod可以指定一组共享存储volumes。Pod中的所有容器都可以访问共享volumes,允许这些容器共享数据。volumes 还用于Pod中的数据持久化,以防其中一个容器需要重新启动而丢失数据。有关Kubernetes如何在Pod中实现共享存储的更多信息。
Pod的问题
pod共享相同的IP地址和端口空间
- 这意味着在同一 pod中的容器运行的 多个进程需要注意不能绑定到相同的端口号, 否则会导致端口冲突,
- 但这只涉及同一pod中的容器。 由于每个pod都有独立的端口空间, 对于不同 pod中的容器来说 则永远不会遇到端口冲突
- 一个 pod中的所有容器也都具有相同的loopback 网络接口, 因此容器可以通过localhost 与同一 pod中的其他容器进行通信。
pod中的容器
- k8s中的思想是:每个容器只安装一个进程,然后多个或一个容器属于一个pod。然后这个pod下的容器可以通过volume的方式共享磁盘。
- 也就是说,应该把整个pod看作虚拟机,然后每个容器相当于运行在虚拟机的进程。
将多层应用分散到多个 pod 中
虽然可以把多个容器放在同一个pod下,但是应该根据应用将容器分布到不同的pod中。原因如下:
- 每个pod是部署再固定的node上的,将前端、后端应用部署在同一个pod里发挥不出集群的作用
- 当需要进行节点扩容的时候,如果前后端在一个pod里,扩容一个pod后就有两个前端、后端,这样多出的前端是没有意义的而且很有难度
何时在pod使用多个容器
- 一般情况下建议单容器pod
- 多容器需要同时扩缩容,是否必须一起运行,代表的是一个主体还是多个独立的组件
Pod的详解
Pod的基本概念
- 最小部署的单元
- 包含多个容器(一组容器的集合)
- 一个Pod中容器共享网络命名空间
- Pod是短暂的
Pod存在的意义
- 创建容器使用docker 一个docker对应一个容器 一个容器有进程 一个容器运行一个应用程序
- Pod是多进程设计 运行多个应用程序
- 一个Pod有多个容器 一个容器运行一个应用程序
- Pod存在为了亲密性应用
- 两个应用之间交互
- 网络之间调用
- 两个应用需要频繁调用
Pod的镜像拉取策略
Pod的资源限制
对资源的限制进行调度 最大或者最小寻找合适的进行调度
Pod的重启策略
Pod的健康检查
Pod的调度
Pod调度主要是根据合适的节点 匹配的资源刚好符合该调度的要求 主要看调度的属性 requests下面的属性内容。
影响资源调度的原因有节点亲和性
节点亲和性又分别为
- 硬亲和性 约束条件必须要满足才可以调度
- 软亲和性 尝试满足 大概就好了
污点和污点忍容
- 影响资源调度的原因还有污点和污点忍容
- 成为污点的时候不被调度到
- 成为污点忍容的时候不一定不被调度到
查看污点情况
添加污点