Kubernetes Pod及容器设计模式

Pod是Kubernetes中最小的调度单元,Pod与容器的比较:

  容器 = 单个进程

  Pod = 多个容器 = 进程组

 
Kubernetes中最小的原子调度单位是Pod,为什么Pod必须是原子调度单位?因为多个容器需要紧密协作。
紧密协作的场景:

  两个进程之间发生文件交换,一个写日志,一个读取日志。

  两个进程需要通过localhost通讯。

  两个容器或者微服务之间需要发生非常频繁的RPC调用,处于性能考虑需要是紧密协作。

  两个容器需要共享某些Linux NameSpace,例如 network namespace。

 
容器之间原本是通过Linux NameSpace和Cgroups隔离开的,Pod需要解决的就是如何打破容器之间的隔离。
Pod设计需要解决2个核心问题:

网络共享

  Infra Container (pause容器) 将自己的 Network Namespace 共享出来

  其他 Container Join To Infra Container Network Namespace

  整个Pod生命周期跟Infra Container一致,与Pod中其他Container无关

存储共享

  Volume是Pod Level,不跟具体某个Container关联。

 
容器设计模式

InitContainer

  比正常的Container优先启动,执行完成任务后立即退出。

Sidecar

  辅助Container

  例如Monitor, Operation,Log,Proxy,Adapter等Container

Pod 内容器的启动顺序按照:初始化容器 -> Sidecar 容器 -> 业务容器 的顺序依次启动。

 
Pod与容器的设计模式本质是: 解耦 -> 每个Container单个进程 重用 ->网络 与 存储
 
 
原文地址:https://www.cnblogs.com/vincenshen/p/13183876.html