Kubernetes3 为什么需要Pod

为什么需要Pod

  1. 在工业实际部署中,经常需要多个进程部署在同一个节点上。类似于Linux操作系统中的进程组的概念(pstree -g 命令查看进程组),他们之间有着”超亲密关系”,例如相互之间会发生直接的文件交换、使用localhost或者Socket文件进行本地通信、共享某些Linux Namespace等。
  2. 容器的”单进程模型”,PID=1的进程往往是应用本身,无法像正常操作系统中的init进程那样拥有进程管理的功能。
  3. 存在”超亲密关系”的进程,需要按照严格的拓扑顺序启动。也就是需要对容器成组进行调度(gang scheduling)。
    基于上述原因,Kubernetes提供了Pod这个逻辑概念,将需要在同一节点上,可能共享Namespace以及其他本地资源的容器进行成组调度。

Pod的实现机制

Pod是逻辑概念,其实是一组共享了某些资源(Network Namespace)的容器组。在没有成组调度时,如要实现容器A和容器B共享网络和Volume,可以通过如下命令实现:

Read more »

Kubernetes2 基本概念

要解决什么问题

可以方便的将用户应用的镜像部署到集群,并提供路由网关、水平扩展、监控、备份灾难恢复等一系列运维能力。这些问题,其实一个PAAS平台都可以解决。

除了解决以上问题,Kubernetes项目区别于其他PAAS平台,重点要解决的问题,来自于Borg项目的研究人员在论文中的一个重要观点:

运行在大规模集群中的各个任务之间,存在着各种各样的关系。这些关系的处理,才是作业编排和管理系统最困难的地方。

需要什么样的架构

  • 节点分为控制节点Master和计算节点Node
  • Master节点包含kube-controller, kube-api-server 和 kube-scheduler三个组件
  • Node节点中的核心组件kubelet:
    • 通过CNI(Container Networking Interface)与网络插件交互,配置容器网络;
    • 通过CSI(Container Storage Interface)与存储插件交互,配置持久化存储;
    • 通过CRI(Container Runtime Interface)与容器运行时交互,定义容器运行时的各项操作。
    • 容器运行时通过OCI容器运行时规范,与Linux操作系统交互。
      Read more »

如何有效地沟通

在吴军老师新书《态度》写给其女儿一封信中,提到了如何有效地沟通:

第一,有效的沟通要以对方确认为准,不要以为话说出去,别人就一定能接收了你传递的信息。
(那么反过来,自己要做到对别人来讲”靠谱”,就是”凡事有交代,件件有着落,事事有回应。”)

第二,要以对方听得懂的话来沟通,不要把简单的问题讲复杂了。 这里作者举了一个很好的例子:

中国的顾维钧先生是一个优秀的外交家,他在1919年的巴黎和会上向西方国家的代表讲述山东省对中国的重要性时,是这样说的:
孔子对中国人来说,相当于耶稣对西方人一样重要。西方人一直把耶路撒冷作为圣地,并且上千年一直要夺回那个地方。
山东是孔子的出生地,它在中国人心中的地位,相当于耶路撒冷在西方人心中的地位。

简单的几句话,就把意思说明白了。对方能听懂,不是因为对山东和孔子有多么熟悉,而是因为熟知耶路撒冷和耶稣。

第三,沟通要简洁,切中要害。对不同的人,表达方式也不一样。

第四,善辩不等于好的沟通,沟通的目的是让对方接受自己的想法,而非把对方驳得哑口无言。

Pattern Service Mesh

当网络刚刚出现

当人们刚想到让两台计算机通信,模型是这样的:

1

但上面过于简单的建模,无法使任意两台计算机之间的通信变得通用。分层的网络协议,使应用之间的通信时,应用本身不用关心网络的底层细节,例如如何拆包粘包,如何将字节序列转化成电信号等等。

2

上面的模型依然存在问题,因为应用A在向B发送请求和数据包时,并不知道B是否能处理过来,如果B不能及时处理网络包,则会丢失数据。因此应用除了业务逻辑之外,还需要有专门的模块控制数据包的发送速度。

3

幸运的是TCP/IP传输层协议的出现,从底层解决了流量控制和拥塞避免的问题,实现了可靠传输。

4

上面的模型也成功的沿用了很长一段时间。

微服务出现

随后计算机逐渐变得便宜,出现了更多的节点和更可靠的网络连接。业界开始使用各种类型的网络系统,出现了更细粒度的分布式agent和面向服务的体系架构(SOA,Service Oriented Architectures)但依旧较重的服务组件。

90年代,Peter Deutsch和他的同事共同提出了有关分布式系统的8条错误假设(The 8 Fallacies of Distributed Computing):

  • 网络是可靠的
  • 没有延迟
  • 带宽无限大
  • 网络是安全的
  • 网络拓扑不会改变
  • 只有一个管理员
  • 传输成本是0
  • 网络是同构的
Read more »

软件设计的哲学(John Ousterhout分享)

软件设计的目标

  1. 软件设计最大的目标是降低软件的复杂性(Complexity),复杂性使软件难于理解和维护。

  2. 复杂性的来源:

    • 含义模糊(Obscurity): 重要信息不突出。
    • 相互依赖:模块无法独立于其他模块而被理解。
  3. 复杂性的危害

复杂性会逐渐递增,前面埋的坑,会导致后面的设计越来越复杂。

设计原则

暴露简单通用的接口,隐藏复杂的实现。

Read more »