k8s容器编排总结

学而时习之，不亦说乎。今天总结一下k8s。k8s（Kubernetes）作为容器编排生态圈中重要一员，是Google大规模容器管理系统borg的开源版本实现，它提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接运行在物理机上。kubernetes是一个开放的容器调度管理平台，不限定任何一种言语，支持java/C++/go/python等各类应用程序 。

kubernetes是一个完备的分布式系统支持平台，支持多层安全防护、准入机制、多租户应用支撑、透明的服务注册、服务发现、内建负载均衡、强大的故障发现和自我修复机制、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力,完善的管理工具，包括开发、测试、部署、运维监控，一站式的完备的分布式系统开发和支撑平台。

一、系统架构

kubernetes系统按节点功能由master和node组成。

Master

Master作为控制节点，调度管理整个系统，包含以下组件：

API Server作为kubernetes系统的入口，封装了核心对象的增删改查操作，以RESTful接口方式提供给外部客户和内部组件调用。它维护的REST对象将持久化到etcd。

Scheduler：负责集群的资源调度，为新建的pod分配机器。这部分工作分出来变成一个组件，意味着可以很方便地替换成其他的调度器。

Controller Manager：负责执行各种控制器，目前有两类：

Endpoint Controller：定期关联service和pod(关联信息由endpoint对象维护)，保证service到pod的映射总是最新的。
Replication Controller：定期关联replicationController和pod，保证replicationController定义的复制数量与实际运行pod的数量总是一致的。

Node

Node是运行节点，运行业务容器，包含以下组件：

Kubelet：责管控docker容器，如启动/停止、监控运行状态等。它会定期从etcd获取分配到本机的pod，并根据pod信息启动或停止相应的容器。同时，它也会接收apiserver的HTTP请求，汇报pod的运行状态。

Kube Proxy：负责为pod提供代理。它会定期从etcd获取所有的service，并根据service信息创建代理。当某个客户pod要访问其他pod时，访问请求会经过本机proxy做转发。

pod 是 kubernetes 的最基本操作单元，包括一个或多个紧密相关的容器，一个 pod 可以被一个容器化的环境看作应用层的“逻辑宿主机”（ Logical host ）。一个 pod 中的多个容器应用通常是紧耦合的。Pod 在 node 上被创建、启动或者销毁。

为什么 kubernetes 使用 pod 在容器之上再封装一层呢？一个很重要的原因是,docker 容器之间通信受到 docker 网络机制的限制。在 docker 的，世界中，一个容器需要通过 link 方式才能访问另一个容器提供的服务（端口）。大量容器之间的 link 将是一个非常繁重的工作。通过 pod 的概念将多个容器组合在一个虚拟的“主机”内，可以实现容器之间仅需通过 localhost 就能相互通信了。

一个pod中的应用容器共享一组资源，如：

pid命名空间：pod中的不同应用程序可以看到其他的进程PID

网络命名空间：pod中的多个容器能够访问同一个IP和端口范围

IPC命名空间：pod中的多个容器能够使用systemV ipc 或POSIX消息队列进行通信。

UTS命名空间：pod中的多个容器共享一个主机名。

Volumes(共享存储卷)：pod中的各个容器可以访问在pod级别定义的volumes。