Kubernetes(1)架构及设计思想

1. 架构

• 全局架构图

  
  
  https://static001.geekbang.org/resource/image/8e/67/8ee9f2fa987eccb490cfaa91c6484f67.png

• Master节点

  • kube-apiserver（负责API服务）
  • kube-scheduler（负责调度）
  • kub-controller-manager（负责容器编排）

  集群的持久化存储，由kube-apiserver处理后保存在Etcd

• 计算节点

  • Networking
  • kubelet
  • 和Container Runtime打交道，通过CRI（Container Runtime Interface）

  只要是可运行的标准镜像容器，都可以通过CRI接入到Kubernetes项目中

  • 通过OCI这个容器运行时规范和底层的Linux系统交互

  把CRI请求翻译成对Linux的系统调用（操作Linux namespace和cgroups等）

  • 通过gRPC协议和Device Plugin插件交互
  • 通过CNI（Container Network Interface）和CSI（Container Storage Interface)，和网络产检和存储插件交互来为容器配置网络和持久化存储
  • Container Runtime

    容器运行时是什么？
    一个由Namespace + Cgroups构成的隔离环境，这部分被称为“容器运行时”，是容器的动态视图。 ref：《Docker（2）容器技术基本概念理解》

  • Volume Plugin
  • Device Plugin
  • ...(Linux OS)

2. Google项目Borg对Kubernetes项目的指导作用

kublet完全是为了实现Kubnetes项目对容器的管理能力而重新实现的一个组件，与Borg之间并没有直接的传承关系。而且Borglet本身也不会对容器进行进行管理。

从一开始，Kubernetes项目就没有向同时期的“容器云”项目那样，把Docker作为整个架构的核心，而是仅仅把它作为最底层的一个容器运行时实现。

3. Kubernetes要着重解决的问题

运行在大规模集群之间的各个任务之间，实际上存在着各种各样的关系。这些关系的处理，才是作业编排和系统管理最重要的地方。如Web应用和DB之间的访问关系、一个负载均衡器和他后端服务的代理关系，一个门户应用与授权组件之间的调用关系。

4 Kubernetes的主要设计思想

从更加宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。

架构设计中，如果要追求项目的普适性，就一定要从顶层开始做好设计。

• 什么是软件的顶层设计？

举例

Kubernetes对容器间的访问进行了分类

• 需要进行非常平频繁的交互和访问的应用，会被部署在同一台机器上，通过Localhost通信，通过本地磁盘目录交换文件。而在Kubernetes项目中，这些容器会被划分为一个Pod，Pod里的容器共享一个Network Namespace、同一组数据卷，从而达到高效交换信息的目的。

• 就是说同一个Pod中，多个Docker容器的Network Namespace是共享的，而不是各自和外部隔离
• Pod、Master节点+计算节点 这两者之间是怎样的关系？

• Web应用和数据库之间的访问关系，Kubernetes会提供一种叫“Service”的服务。像这两种应用往往故意不部署在同一个物理节点上，这样即使Web应用所在机器宕机了，数据库不会受到影响。

Service服务的主要作用：作为Pod的代理入口（Portal），从而代理Pod对外暴露一个固定的网络地址。作用是，解决对于一个容器来说，他的IP信息是不固定的，但是通过给Pod绑定一个Service服务作为Pod的代理入口，就能够固定下（数据库）的访问的网络地址。而Service后端真正代理Pod的IP地址、端口等信息的自动更新、维护，则是Kubernetes项目的职责。

• 提问：
  为什么对于一个容器来说，他的IP信息是不固定的？？

4.1 应用访问的鉴权

Kubernetes提供了一种叫做Secret的对象存储在Etcd中的键值对数据。在Kubernetes会在用户指定的Pod启动时，自动将Secret中的数据以Volume的方式挂载到容器（如Web应用容器）里。这样（Web应用）容器就可以访问数据库了。

4.2 应用的运行形态

除了应用之间的关系之外，应用运行的形态是影响“如何容器化这个应用”的第二个重要原因。因此，kubernetes定制了基于Pod的改造后的对象。如：

形态	场景
Job	描述一次性运行的Pod（如大数据任务）
DaemonSet	描述每个宿主机上必须且只能运行一个副本的守护进程服务
CronJob	描述定时任务
...	...

4.3 声明式API

Kubernetes并没有像其他项目一样，为每个管理功能创建一个指令，然后在项目中实现其中的逻辑。这种做法的在拓展性上不好。
Kubernetes的做法是：

+ 通过一个“编排对象”，如Pod， Job，CronJob等，来描述用户试图管理的应用；

+ 然后，再为他定义一些“服务对象”，比如Service， Secret， Horizaontal Pod Autoscaler(水平拓展器）等负责具体的平台级功能。

这两点Kubernetes的最核心的设计理念

4.4 Kubernetes项目核心功能的“全景图”

5. Kubernetes的使用（Kubernetes如何启动一个容器化任务）

先说怎么用，后续博文补充细节
场景： 做好了一个Nginx容器镜像，希望通过平台启动这个镜像。并且，运行两个完全相同的Nginx副本，以负载均衡的方式共同对外提供服务。

Step 1 编写一个Yaml文件

nginx-deployment.yaml(核心是spec.template部分)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

Step 2 执行

  $ kubectl create -f nginx-deployment.yaml

搞定，也正是在这种“声明式API”的基础上，才能够实现强大的编排能力。

编排是什么？
过去很多集群管理项目，比如Yarn、Mesos和Swarm所擅长的，是把一个容器，按照某种规则，放置在某个最佳节点运行起来，这种功能被叫做“调度”。
而Kubernetes做的事情是，按照用户的意愿和整个系统的规则，完全自动化地处理好容器之间的各种关系。这种功能，就是编排。所以说，Kubernetes的本质，是为用户提供一个具有普遍意义的容器编排工具。
更重要的是，Kubernetes项目为用户提供的了一套基于容器构建分布式系统的基础依赖。

后续的博文，会重点关注Kubernetes里面到底是如何实现的，来加深对本文中Kubernetes架构和设计思想和理解。

思考题：

1. Docker Swarm（SwarmKit项目）和Kubernetes在架构和使用方法上有什么区别？
2. 在Kubernetes之前，有很多项目都没办法管理“有状态”的容器，就是说，不能从一台宿主机“迁移”到另一台宿主机上的容器。你是否能列举出，组织这种迁移的原因。