前言
容器技术虽然解决了应用和基础设施异构的问题，让应用可以做到一次构建，多次部署，但在复杂的微服务场景，单靠 Docker 技术还不够，它仍然有以下问题没有解决：
- 一个容器故障停机了，怎么样保证高可用让另外一个容器立刻启动去替补上停机的容器
- 当并发访问量上来的时候，是否可以做到自动扩容，并发访问量下去的时候是否可以做到自动缩容
- ...
容器的问题确实有时候挺值得深思的，而这些容器管理的问题统称为 容器编排 问题，我们能想到的问题，自然有人去解决，例如 docker 自家就推出了 Docker Swarm 容器编排工具，Apache 推出了 Mesos 资源统一管控工具，Google 推出了Kubernetes容器编排工具，而这也是我们要说到的主角！
Kubernetes简介
首先Kubernetes首字母为K，末尾为s，中间一共有8个字母，所以简称K8s,docker的logo是一个鲨鱼，K8s的logo是一个方向盘，舵手的意思，代表的就是这群鲨鱼的领航者
Kubernetes最初源于谷歌内部的Borg，后面谷歌使用go语言基于Borg的设计思路开发了Kubernetes，Kubernetes 的最初目标是为应用的容器化编排部署提供一个最小化的平台，目前已捐赠给CNCF，已经开源。
Kubernetes 是一个轻便的和可扩展的开源平台，用于管理容器化应用和服务。通过Kubernetes 能够进行应用的自动化部署和扩缩容。在Kubernetes 中，会将组成应用的容器组合成一个逻辑单元以更易管理和发现。Kubernetes 积累了作为Google 生产环境运行工作负载15 年的经验，并吸收了来自于社区的最佳想法和实践。
Kubernetes 发展
- 2014年6月谷歌云计算专家Eric Brewer在旧金山的发布会为这款新的开源工具揭牌。
- 2015年7月22日K8S迭代到 v 1.0并在OSCON大会上正式对外公布。
- 为了建立容器编排领域的标准和规范，Google、RedHat 等开源基础设施领域玩家们，在 2015 年共同牵头发起了名为 CNCF（Cloud Native Computing Foundation）的基金会。Kubernetes 成为 CNCF 最核心的项目。发起成员：AT&T, Box, Cisco, Cloud Foundry Foundation, CoreOS, Cycle Computing, Docker, eBay, Goldman Sachs, Google, Huawei, IBM, Intel, Joyent, Kismatic, Mesosphere, Red Hat, Switch SUPERNAP, Twitter, Univa, VMware and Weaveworks。
- 2019-07 阿里云宣布 Docker Swarm 剔除
- 2018年，超过 1700 开发者成为 Kubernetes 项目社区贡献者，全球有 500 多场沙龙。国内出现大量基于 Kubernetes 的创业公司。
- 2020 年，Kubernetes 项目已经成为贡献者仅次于 Linux 项目的第二大开源项目。成为了业界容器编排的事实标准，各大厂商纷纷宣布支持 Kubernetes 作为容器编排的方案。
K8s特性
- 轻量级，对系统资源消耗小
- 免费开源
- 自我修复：一旦某一个容器崩溃，能够在1秒左右迅速启动新的容器
- 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
- 服务发现：服务可以通过自动发现的形式找到它所依赖的服务
- 负载均衡：如果一个服务启动了多个容器，能够自动实现请求的负载均衡
- 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
- 存储编排：可以根据容器自身的需求自动创建存储卷
k8s 整体架构
k8s 中几种常见的资源
- Master： 集群控制节点，每个集群都至少需要一个 master 节点负责集群的管控，可以理解为集群的大脑
- Node： 从字面上来看Work Node就是用来工作的，也就是真正承担服务的机器节点。如服务A部署到K8S后，由 master 分配容器到这些 node 节点上，然后 node 节点上的docker 负责容器的运行
- Pod： kubernetes的最小控制单元，容器都是运行在 pod 中的，一个pod中可以有 1 个或多个容器
- Controller： 控制器，通过它来实现对 pod 的管理，比如启动 pod，停止 pod，伸缩 pod 的数量等等
- Service： pod 对外服务的统一入口，可以维护同一类的多个 pod
- Label： 标签，用于对 pod 进行分类，同一类的 pod 会拥有相同的标签
- NameSpace： 命名空间，用来隔离 pod 的运行环境
核心组件
apiserver
- 提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能。
controller manager
- 负责维护集群的状态，比如副本期望数量、故障检测、自动扩展、滚动更新等
scheduler
- 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上
etcd
- 键值对数据库，用于持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操作etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。
kubelet
- 负责维护容器的生命周期，同时也负责 Volume 和网络的管理
kube-proxy
- 负责为 Service 提供 cluster 内部的服务发现和负载均衡
Container runtime
- 负责镜像管理以及 Pod 和容器的真正运行
