• 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单个进程 重用 ->网络 与 存储
     
     
  • 相关阅读:
    SNMP、rrdtool
    mysqldump命令备份数据
    Ansible之playbook&&roles
    敏捷软件开发 原则、模式与实践 第9章的例子程序(C#版)
    iis websocket
    EDM 邮件营销 html&css编写建议和规范整理
    Microsoft .NET Framework
    线程上下文切换
    系统调用 用户态 内核态
    文件系统
  • 原文地址:https://www.cnblogs.com/vincenshen/p/13183876.html
Copyright © 2020-2023  润新知