kubernetes 入门与实践
1. kubernetes/K8S 是什么？
Kubernetes 是一个可移植、可扩展的、开源的容器管理平台，可以对容器进行自动化部署、自动化扩缩容、跨主机管理等，简称 K8S。K8S 提供了应用程序的升级和回滚的能力，可以对代码进行灰度发布、金丝雀发布、蓝绿发布、滚动更新等。提供了一套完整的监控系统和日志收集平台，具有故障自恢复的能力。利用 service 可以实现服务注册、发现和四层负载均衡，利用 ingress 可以实现七层负载均衡，通过coredns 可实现域名解析等。K8S 支持在多种平台部署，可在私有云，公有云，混合云，openstack、openshift、VMware vSphere，VMware workstation，物理机、云主机等环境部署。
docker 官方 logo：
kubernetes 官方 logo：
它是一个舵，舵是轮船的方向盘，船在大海里航行就要靠舵来掌控方向，Docker 是集装箱，可以把杂乱的货物整理归类，那 kubernetes 就是运送集装箱的船的方向盘，所以叫做舵。
2. kubernetes 起源和发展前景
Kubernetes 单词起源于希腊语, 是“舵手”或者“领航员、飞行员”的意思。
来源于 Google 的 Borg 项目：
Borg 是谷歌内部的一个容器编排工具，谷歌业务 90%以上都在 Borg 上运行，Borg 在谷歌内部已经使用了大概 15 年。 K8S 是在 Borg 的基础上开发出来的轻量级容器编排工具。K8S 的根基非常牢固，得益于 Borg 过去十数年间积累的经验和教训，是站在巨人的肩膀上发展起来的项目。开源之后，迅速称霸容器编排技术领域。
Kubernetes 的发展状况：
京东：
2016 年底，京东业务开始从 OpenStack 切换到 Kubernetes，第一阶段迁移 20%的业务到kubernetes，集群规模是 500+物理节点，2w+Pod 容器。
2020 年，京东实现 90%的业务切换到 kubernetes，集群规模达到上万个节点，百万 Pod 容器阿里巴巴：管理几十个 K8S 集群，其中最大的集群约 1 万个节点，每个集群会运行几十万个应用，api 的 QPS 达到1000 万+。
kubernetes 发展历史：
- 2014.6
谷歌云计算专家埃里克·布鲁尔（Eric Brewer）在旧金山的发布会宣布开源 kubernetes，它由 Joe Beda、 Brendan Burns 以及 Craig McLuckie 带头创建，之后华为、微软、redhat 等公司纷纷引入 kubernetes。 - 2014.9
Kubernetes 开始内测，发布第一个测试版本 0.2. - 2015.7
Kubernetes 开始正式对外使用，发布第一个正式版本 1.0。 4. 2016.12
发布 1.5 版本。 - 2017.10
Docker 官方宣布支持 Kubernetes。这标志着 kubernetes 将成为容器编排领域的大佬。 - 2018 年
2018.3 发布 1.10 版本，CNCF 宣布 Kubernetes 正式毕业 - 2019 年
2019.3 发布 1.14 版本 - 2020 年
2020.8 发布 1.19 版本
2020.12 发布 1.20 版本，宣布不在支持 docker，由于 Docker 镜像遵循开放容器倡议（OCI）镜像规范，所以 Docker 产生的镜像能在所有 CRI （容器运行时接口标准）兼容运行时的集群中正常使用。也就是说 docker+k8s 这套还可以继续用，不需要过度担心。
目前大约是每 100 天更新一次版本，更新速度相当快。常见的容器编排工具： - docker-compose：单机环境下管理 docker
- Docker Swarm：
docker 自己的容器编排工具，可以管理 docker 集群 - Apache Mesos and Marathon：
Mesos 是一个数据中心的资源统一管控的工具，本身没有编排容器的功能，需要和 Marathon 结合使用。后来 Apache Mesos 自己说不但支持 Marathon 也支持 Kubernetes，且当时 docker 也说不但原生支持 docker swarm 也支持 k8s，k8s 的地位已经显而易见了。
3. kubernetes 特性
自我修复弹性伸缩
自动部署和回滚
服务发现和负载均衡机密和配置管理
存储编排批处理
4. kubernetes 架构
先看下 Borg 项目的架构：
k8s 的物理架构是 master/node 模式：
K8S 集群至少需要一个主节点(Master)和多个工作节点(Worker)单 master 节点架构图如下：
Master 节点是集群的控制节点，负责整个集群的管理和控制，主节点主要用于暴露 API，调度部署和节点的管理。工作节点主要是运行容器的。
5. kubernetes 架构详细拆分-组件介绍
kubectl：管理 k8s 的命令行工具，可以操作 k8s 中的资源对象。
etcd： 是一个高可用的键值数据库，存储 k8s 的资源状态信息和网络信息的，etcd 中的数据变更是通过
api server 进行的。
apiserver: 提供 k8s api，是整个系统的对外接口，提供资源操作的唯一入口，供客户端和其它组件调用，提供了 k8s 各类资源对象（pod,deployment,Service 等）的增删改查，是整个系统的数据总线和数据中心，并提供认证、授权、访问控制、API 注册和发现等机制，并将操作对象持久化到 etcd 中。相当于“营业厅”。
scheduler：负责 k8s 集群中 pod 的调度的 ， scheduler 通过与 apiserver 交互监听到创建 Pod 副本的信息后，它会检索所有符合该 Pod 要求的工作节点列表，开始执行 Pod 调度逻辑。调度成功后将 Pod绑定到目标节点上，相当于“调度室”。
controller-manager：与 apiserver 交互，实时监控和维护 k8s 集群的控制器的健康情况，对有故障的进行处理和恢复，相当于“大总管”。
kubelet： 每个 Node 节点上的 kubelet 定期就会调用 API Server 的 REST 接口报告自身状态，API
Server 接收这些信息后，将节点状态信息更新到 etcd 中。kubelet 也通过API Server 监听 Pod 信息，从而对 Node 机器上的 POD 进行管理，如创建、删除、更新 Pod
kube-proxy：提供网络代理和负载均衡，是实现 service 的通信与负载均衡机制的重要组件，kube-
proxy 负责为 Pod 创建代理服务，从 apiserver 获取所有 service 信息，并根据 service 信息创建代理服务，实现 service 到 Pod 的请求路由和转发，从而实现 K8s 层级的虚拟转发网络，将到 service 的请求转发到后端的 pod 上。
多 master 节点高可用架构图如下：
6. kubernets 中的资源对象
6.1 Pod
Pod 是 Kubernetes 中的最小调度单元，当指派容器时，容器实际上并不会指派到物理硬件上，容器会被分配到一个 Pod 里。Pod 代表集群上正在运行的一个进程，一个 Pod 封装一个容器（也可以封装多个容器），Pod 里的容器共享存储、网络等。也就是说，应该把整个 pod 看作虚拟机，然后每个容器相当于运行在虚拟机的进程。
Pause 容器
每个 pod 中都存在一个 pause 容器。Pod 中除了 Pause 之外的其他容器可以称之为业务容器。
pause 容器主要为每个业务容器提供以下功能：
PID 命名空间：Pod 中的不同应用程序可以看到其他应用程序的进程 ID。网络命名空间：Pod 中的多个容器能够访问同一个 IP 和端口范围。
IPC 命名空间：Pod 中的多个容器能够使用 SystemV IPC 或 POSIX 消息队列进行通信。
UTS 命名空间：Pod 中的多个容器共享一个主机名和 Volumes（共享存储卷）。
6.2 label
label 是标签的意思，k8s 中的资源对象大都可以打上标签，如 Node、Pod、Service 等，一个资源可以绑定任意多个 label，k8s 通过 Label 可实现多维度的资源分组管理，后续可通过 Label Selector 查询和筛选拥有某些 Label 的资源对象，例如创建一个 Pod，给定一个 Label 是 app=tomcat，那么service 可以通过 label selector 选择拥有 app=tomcat 的 pod，和其相关联，也可通过 app=tomcat删除拥有该标签的 Pod 资源。
6.3 Replicaset
Kubernetes 中的副本控制器，管理Pod，使 pod 副本的数量始终维持在预设的个数。
6.4 Deployment
管理Replicaset 和Pod 的副本控制器，Deployment 可以管理多个Replicaset，是比 Replicaset更高级的控制器，也即是说在创建 Deployment 的时候，会自动创建 Replicaset，由 Replicaset再创建 Pod，Deployment 能对Pod 扩容、缩容、滚动更新和回滚、维持 Pod 数量。
6.5 Service
在 kubernetes 中，Pod 是有生命周期的，如果 Pod 重启 IP 很有可能会发生变化。如果我们的服务都是将 Pod 的 IP 地址写死，Pod 的挂掉或者重启，和刚才重启的 pod 相关联的其他服务将会找不到它所关联的 Pod，为了解决这个问题，在 kubernetes 中定义了 service 资源对象，Service 定义了一个服务访问的入口，客户端通过这个入口即可访问服务背后的应用集群实例，service 是一组 Pod 的逻辑集合，这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector 实现的。
可以看下面的图：
6.6 Coredns
在 k8s 中，coredns 会监听 3 类 k8s 资源，分别是 Service、StatefulSet 和 Pod，并会为这三类资源自动创建（更新/删除）相应的域名记录，k8s 中各服务间可以直接通过服务域名的方式进行通信。
6.7 kube-proxy
部署在每个 Node 节点上，它是实现 Kubernetes Service 的通信与负载均衡机制的重要组件， kube- proxy 负责为 Pod 创建代理服务，从 apiserver 获取所有 server 信息，并根据 service 信息创建代理服务，实现 server 到 Pod 的请求路由和转发，从而实现 K8s 层级的虚拟转发网络。