范彬 译 分布式实验室
Kubernetes是容器管理平台， 运行企业级、云应用和网络可扩展的IT负载。它是建立在谷歌奠定的15年运行容器化应用的经验基础上。这本电子书的目的是突出Kubernetes如何被早期采用者部署。它涉及到使用模式和生产环境使用Kubernetes的用户的关键部署场景。我们也会看到一些公司，如：华为、IBM、英特尔和Red Hat，他们努力推动Kubernetes前进。
容器的概念已经存在了十多年。主流UNIX的操作系统（OS），如Solaris、FreeBSD和Linux内建支持容器，但Docker是真正面向开发和IT运维团队，使容器变成可管理和可访问。Docker已经演示容器可以驱动应用程序可扩展性和可移植性。开发人员和IT运维人员开始转向使用容器包装各种语言的代码和依赖关系 。容器在DevOps流程中也发挥了至关重要的作用。他们已成为建设自动化和持续集成和连续部署（CI / CD）管道的一个组成部分。
对容器的兴趣导致了OCI格式的形成。业界也目睹了容器的各种实现，如标准的LXD，CoreOS的Rocket， Windows容器cri-o（已经被Kubernetes孵化器审查通过）， VMware集成容器的vSphere 。
虽然这些核心实现围绕单个容器生命周期，而典型的生产应用需要处理运行在跨主机上的容器的负载。处理跨主机和生产环境要求的复杂结构需要一些管理工具，一些流行的解决方案包括Docker Datacenter，Kubernetes和Mesosphere DC/OS。
容器编排已经影响了传统平台PaaS的结构，它们将提供开放和有效的模式支持打包、部署、隔离、服务发现、扩容和滚动更新。最主流的PaaS解决方案已经拥抱容器，并有新的PaaS 建立在容器编排之上实现管理平台。客户可以选择部署，或面向IT运维，部署核心容器编排工具； 或面向开发者，使用PaaS平台 。
关键的卖点是容器编排已经影响驱动企业和新兴的初创公司采用容器起重要作用。
像大多数的分布式计算平台，一个Kubernetes集群包括至少一个主节点和多个计算节点。主节点暴露应用程序接口（API），调度部署和管理整个集群。
Node：每个节点都有一个容器运行时，如Docker或Rocket，以及与主节点通信的agent 。节点还运行日志、监视、服务发现和可选附加组件的其他组件。节点是Kubernetes集群的工作负荷节点，他们给应用提供计算，网络，存储资源。节点可能是云上的虚拟机或数据中心的裸机。
Pod：Pod是一个或多个容器的集合。Pod是Kubernetes管理的核心单元，作为共享相同上下文和资源的容器的逻辑边界，一组进程。在运行时，pods可以通过创建副本扩容， 确保部署始终运行所需数量的pods。
Replica sets：通过始终维护一组预定义的pods，提供所需的规模和可用性。单个pod或replica set能通过services暴露给内部或外部消费者。services通过特定的标准将一组Pods关联来实现对pods的发现。通过键值对的标签和选择器来关联pods，任何与标签匹配的新pod将自动被服务发现。
Kubernetes对象（如pods，replica sets和services。）被提交给主节点，基于需求定义和资源可用性，主节调度到指定节点的pod。该节点从容器镜像仓库中提取镜像并协调本地容器运行时启动容器。
Etcd：etcd是CoreOS开源，分布式健值数据库，做为kubernetes集群所有组件的（single source of truth ） SSOT。主节点需要etcd获得节点状态，pods状态和容器状态参数信息。Kubernetes框架通过创建应用和底层架构的抽象层，达到模块化和可扩展。
Kubernetes的设计原则是可扩展性、可用性，安全将任务分发到可用的资源。本节将重点介绍一些Kubernetes的关键属性。
负载可扩展性
应用程序打包成微服务部署在Kubernetes上 。这些微服务是由多个容器分组成pods。每个容器的设计只执行一个任务。pod可以由无状态容器或状态容器组成。无状态的pod可以轻易按比例要求扩展或通过动态自动扩展。Kubernetes1.4支持平行pod自动扩展，即可以基于CPU自动扩展replication controller中pods数量。未来的版本将通过定义自动扩展原则，支持用户量度和阈值。
谷歌云托管Kubernetes运行支持集群自动扩展。当在所有可用的节点pods扩展，Kubernetes协同底层基础设施向集群添加节点。
一个应用程序架构是微服务架构，以容器封装部署为pods，可以利用Kubernetes的极端的扩展功能。虽然这主要是适用于无状态的pods， Kubernetes通过pet sets增加支持持久化工作负载，如：NoSQL数据库与关系数据库管理系统（RDBMS）；同时将能扩展无状态的应用，如：Cassandra集群和MongoDB副本集。这种能力将使弹性的、无状态的Web层和持久的、有状态的数据库共同运行在相同的基础设施上。
高可用
当代工作负载要求在基础设施和应用水平上。在扩展集群中，一切都容易失败，这使得生产负载的高可用性严格必要。更多的容器编排引擎和PaaS提供实现应用程序的可用性， Kubernetes是设计用来解决基础设施和应用程序的可用性。
在应用方面，Kubernetes通过replica sets，replication controllers和pet sets确保应用程序的高可用。运维能定义在某个指定时间点的最小pods数。如果容器和pod因为错误崩溃，预设策略能回到预定的配置部署。有状态负载通过pet sets能被配置成高可用的。
对于基础设施的可用性，Kubernetes已经支持大范围的分布式文件系统的存储：如NFS和GlusterFS，块存储设备如Amazon EBS和谷歌计算引擎persistent disk，专业容器存储插件如：Flocker。通过增加一个可靠的可用的存储层，Kubernetes保证有状态的工作负载的高可用性。
Kubernetes集群的每个组件-etcd, API服务器,节点–可配置成高可用。通过负载均衡器和健康检查确保应用程序的高可用。
安全
Kubernetes的安全性可以通过多层次的配置。API接口通过传输层安全TLS，确保用户使用最安全的机制认证。Kubernetes集群有两类用户-服务账户直接由Kubernetes管理的，普通用户认为是由一个独立的服务管理。服务帐户由API服务器自动创建的Kubernetes API管理的。管理集群内运行的进程的每一个操作必须由已验证的用户启动；该机制确保集群的安全性。
部署Kubernetes集群内应用可以利用secret的概念来安全地访问数据。一个secret是Kubernetes对象，包含少量的敏感数据，如密码、令牌或密钥，从而减少意外的数据暴露的风险。用户名和密码以base64编码存储一个Kubernetes集群内。在运行时pods通过安装的卷或环境变量可以访问secret。需要注意的是，secret对同一集群命名空间的所有用户都可用。
通过部署网络策略限制pods的网络流量。Kubernetes的网络策略是规范pods选择如何相互通信以及与其他网络的通信。这对于在多层部署中不暴露于其他应用程序的pods是非常有用的。
可兼容性
Kubernetes的设计在选择操作系统、Docker运行时，处理器架构，云平台和PaaS提供了选择的自由。
Kubernetes集群可以配置在主流Linux系统上，包括CentOS，CoreOS，Debian，Fedora，Red Hat Linux的Ubuntu。它可以部署运行在本地开发机；云平台，如AWS，Azure和谷歌云；基于KVM的虚拟环境，vSphere和libvirt；及裸机。用户可以启动Docker或rkt，未来新的容器运行时的容器。
通过fedreation，可以混合匹配集群，使之运行在跨多云提供商和私有部署 。这将给容器化的工作负载带来混合云能力。客户可以无缝移动工作负载从一个部署目标转移到另一个部署目标。我们将在下一节讨论混合架构。
