共计 4941 个字符，预计需要花费 13 分钟才能阅读完成。
简介： Docker 虽好用，但面对弱小的集群，成千上万的容器，忽然感觉不香了。这时候就须要咱们的配角 Kubernetes 上场了，先来理解一下 Kubernetes 的基本概念，前面再介绍实际，由浅入深步步为营。
镜像下载、域名解析、工夫同步请点击 阿里巴巴开源镜像站
Docker 虽好用，但面对弱小的集群，成千上万的容器，忽然感觉不香了。
这时候就须要咱们的配角 Kubernetes 上场了，先来理解一下 Kubernetes 的基本概念，前面再介绍实际，由浅入深步步为营。
对于 Kubernetes 的基本概念咱们将会围绕如下七点开展：
一、Docker 的治理痛点
如果想要将 Docker 利用于宏大的业务实现，是存在艰难的编排、治理和调度问题。于是，咱们迫切需要一套管理系统，对 Docker 及容器进行更高级更灵便的治理。
Kubernetes 应运而生！Kubernetes，名词源于希腊语，意为「舵手」或「飞行员」。Google 在 2014 年开源了 Kubernetes 我的项目，建设在 Google 在大规模运行生产工作负载方面领有十几年的教训的根底上，联合了社区中最好的想法和实际。
K8s 是 Kubernetes 的缩写，用 8 代替了「ubernete」，下文咱们将应用简称。
二、什么是 K8s？
K8s 是一个可移植的、可扩大的开源平台，用于治理容器化的工作负载和服务，可促成申明式配置和自动化。K8s 领有一个宏大且快速增长的生态系统。K8s 的服务、反对和工具宽泛可用。
通过 K8s 咱们能够：
- 疾速部署利用
- 疾速扩大利用
- 无缝对接新的利用性能
- 节俭资源，优化硬件资源的应用
K8s 有如下特点：
- 可移植：反对私有云，公有云，混合云，多重云 multi-cloud
- 可扩大：模块化，插件化，可挂载，可组合
- 自动化：主动部署，主动重启，主动复制，主动伸缩 / 扩大
三、云架构 & 云原生
云和 K8s 是什么关系
云就是应用容器构建的一套服务集群网络，云由很多的大量容器形成。K8s 就是用来治理云中的容器。
常见几类云架构
- On-Premises（本地部署）
- IaaS（基础设施即服务）
用户：租用（购买 | 调配权限）云主机，用户不须要思考网络，DNS，硬件环境方面的问题。
运营商：提供网络，存储，DNS，这样服务就叫做基础设施服务
- PaaS（平台即服务）
MySQL/ES/MQ/…… - SaaS（软件即服务）
钉钉
财务管理
- Serverless
无服务，不须要服务器。站在用户的角度思考问题，用户只须要应用云服务器即可，在云服务器所在的根底环境，软件环境都不须要用户关怀。
能够预感：将来服务开发都是 Serverless，企业都构建了本人的公有云环境，或者是应用私有云环境。
云原生
为了让应用程序（我的项目，服务软件）都运行在云上的解决方案，这样的计划叫做云原生。
云原生有如下特点：
- 容器化，所有服务都必须部署在容器中
- 微服务，Web 服务架构式服务架构
- CI/CD
- DevOps
四、K8s 架构原理
K8s 架构
概括来说 K8s 架构就是一个 Master 对应一群 Node 节点。
上面咱们来逐个介绍 K8s 架构图中的 Master 和 Node。
Master 节点构造
- apiserver 即 K8s 网关，所有的指令申请都必须要通过 apiserver；
- scheduler 调度器，应用调度算法，把申请资源调度到某一个 Node 节点；
- controller 控制器，保护 K8s 资源对象；
- etcd 存储资源对象；
Node 节点
- kubelet 在每一个 Node 节点都存在一份，在 Node 节点上的资源操作指令由 kubelet 来执行；
- kube-proxy 代理服务，解决服务间负载平衡；
- Pod 是 k8s 治理的根本单元（最小单元），Pod 外部是容器，k8s 不间接治理容器，而是治理 Pod；
- Docker 运行容器的根底环境，容器引擎；
- Fluentd 日志收集服务；
在介绍完 K8s 架构后，咱们又引入了很多技术名词。不要焦急，先有整体概念，再各个击破。请急躁浏览下文，置信你肯定会有不一样的播种。
五、K8s 外围组件
K8s 组件
- K8s 是用来治理容器，然而不间接操作容器，最小操作单元是 Pod（间接治理容器）。
- 一个 Master 有一群 Node 节点与之对应
- Master 节点不存储容器，只负责调度、网管、控制器、资源对象存储
- 容器的存储在 Node 节点，容器是存储在 Pod 外部的）
- Pod 外部能够有一个容器，或者多个容器
- Kubelet 负责本地 Pod 的保护
- Kube-proxy 负责负载平衡，在多个 Pod 之间来做负载平衡
Pod 是什么？
- Pod 也是一个容器，这个容器中装的是 Docker 创立的容器，Pod 用来封装容器的一个容器，Pod 是一个虚拟化分组；
- Pod 相当于独立主机，能够封装一个或者多个容器。
Pod 有本人的 IP 地址、主机名，相当于一台独立沙箱环境。
Pod 到底用来干什么？
通常状况下，在服务部署时候，应用 Pod 来治理一组相干的服务。一个 Pod 中要么部署一个服务，要么部署一组有关系的服务。
一组相干的服务是指：在链式调用的调用连路上的服务。
Web 服务集群如何实现？
实现服务集群：只须要复制多方 Pod 的正本即可，这也是 K8s 治理的先进之处，K8s 如果持续扩容，只须要管制 Pod 的数量即可，缩容情理相似。
Pod 底层网络，数据存储是如何进行的？
- Pod 外部容器创立之前，必须先创立 Pause 容器；
- 服务容器之间拜访 localhost，相当于拜访本地服务一样，性能十分高。
ReplicaSet 正本控制器
管制 Pod 正本「服务集群」的数量，永远与预期设定的数量保持一致即可。当有 Pod 服务宕机时候，正本控制器将会立马从新创立一个新的 Pod，永远保障正本为设置数量。
正本控制器：标签选择器 - 抉择保护一组相干的服务（它本人的服务）。
selector：app = web
Release = stable- ReplicationController 正本控制器：单选
- ReplicaSet 正本控制器：单选，复合抉择
在新版的 K8s 中，倡议应用 ReplicaSet 作为正本控制器，ReplicationController 不再应用了。
Deployment 部署对象
- 服务部署构造模型
- 滚动更新
ReplicaSet 正本控制器管制 Pod 正本的数量。然而，我的项目的需要在一直迭代、一直的更新，我的项目版本将会不停的的发版。版本的变动，如何做到服务更新？
部署模型：
- ReplicaSet 不反对滚动更新，Deployment 对象反对滚动更新，通常和 ReplicaSet 一起应用；
- Deployment 治理 ReplicaSet，RS 从新建设新的 RS，创立新的 Pod。
MySQL 应用容器化部署，存在什么样的问题？
- 容器是生命周期的，一旦宕机，数据失落
- Pod 部署，Pod 有生命周期，数据失落
对于 K8s 来说，不能应用 Deployment 部署有状态服务。
通常状况下，Deployment 被用来部署无状态服务，那么对于有状态服务的部署，应用 StatefulSet 进行有状态服务的部署。
什么是有状态服务？
有实时的数据须要存储
有状态服务集群中，把某一个服务抽离进来，一段时间后再退出机器网络，如果集群网络无奈应用
什么是无状态服务？
- 没有实时的数据须要存储
- 无状态服务集群中，把某一个服务抽离进来，一段时间后再退出机器网络，对集群服务没有任何影响
StatefulSet
- 为了解决有状态服务应用容器化部署的一个问题。
- 部署模型
- 有状态服务
StatefulSet 保障 Pod 从新建设后，Hostname 不会发生变化，Pod 就能够通过 Hostname 来关联数据。
六、K8s 的服务注册与发现
Pod 的构造是怎么的？
- Pod 相当于一个容器，Pod 有独立 IP 地址，也有本人的 Hostname，利用 Namespace 进行资源隔离，独立沙箱环境。
- Pod 外部封装的是容器，能够封装一个，或者多个容器（通常是一组相干的容器）
Pod 网络
- Pod 有本人独立的 IP 地址
- Pod 外部容器之间拜访采纳 Localhost 拜访
Pod 外部容器拜访是 Localhost，Pod 之间的通信属于近程拜访。
Pod 是如何对外提供服务拜访的？
Pod 是虚构的资源对象（过程），没有对应实体（物理机，物理网卡）与之对应，无奈间接对外提供服务拜访。
那么该如何解决这个问题呢？
Pod 如果想要对外提供服务，必须绑定物理机端口。也就是说在物理机上开启端口，让这个端口和 Pod 的端口进行映射，这样就能够通过物理机进行数据包的转发。
概括来说：先通过物理机 IP + Port 进行拜访，再进行数据包转发。
一组相干的 Pod 正本，如何实现拜访负载平衡？
咱们先明确一个概念，Pod 是一个过程，是有生命周期的。宕机、版本更新，都会创立新的 Pod。这时候 IP 地址会发生变化，Hostname 会发生变化，应用 Nginx 做负载平衡就不太适合了。
所以咱们须要依赖 Service 的能力。
Service 如何实现负载平衡？
简略来说，Service 资源对象包含如下三局部：
- Pod IP：Pod 的 IP 地址
- Node IP：物理机 IP 地址
- Cluster IP：虚构 IP，是由 K8s 形象出的 Service 对象，这个 Service 对象就是一个 VIP 的资源对象
Service VIP 更深刻原理探讨
- Service 和 Pod 都是一个过程，Service 也不能对外网提供服务；
- Service 和 Pod 之间能够间接进行通信，它们的通信属于局域网通信；
- 把申请交给 Service 后，Service 应用 iptable，ipvs 做数据包的散发。
Service 对象是如何和 Pod 进行关联的？
- 不同的业务有不同的 Service；
- Service 和 Pod 通过标签选择器进行关联；
selector：app=x 抉择一组订单的服务 pod，创立一个 service；通过 endpoints 寄存一组 pod ip；Service 通过标签选择器抉择一组相干的正本，而后创立一个 Service。
Pod 宕机、公布新的版本的时候，Service 如何发现 Pod 曾经产生了变动？
每个 Pod 中都有 Kube-Proxy，监听所有 Pod。如果发现 Pod 有变动，就动静更新（etcd 中存储）对应的 IP 映射关系。
七、关键问题
企业应用 K8s 次要用来做什么？
自动化运维平台，守业型公司，中小型企业，应用 K8s 构建一套自动化运维平台，主动保护服务数量，放弃服务永远和预期的数据放弃一致性，让服务能够永远提供服务。这样最间接的益处就是降本增效。
充分利用服务器资源，互联网企业，有很多服务器资源「物理机」，为了充分利用服务器资源，应用 K8s 构建公有云环境，我的项目运行在云。这在大型互联网公司尤为重要。
服务的无缝迁徙，我的项目开发中，产品需要不停的迭代，更新产品。这就意味着我的项目不停的公布新的版本，而 K8s 能够实现我的项目从开发到生产无缝迁徙。
K8s 服务的负载平衡是如何实现的？
Pod 中的容器很可能因为各种起因产生故障而死掉。Deployment 等 Controller 会通过动态创建和销毁 Pod 来保障利用整体的健壮性。换句话说，Pod 是软弱的，但利用是强壮的。每个 Pod 都有本人的 IP 地址。当 controller 用新 Pod 代替产生故障的 Pod 时，新 Pod 会调配到新的 IP 地址。
这样就产生了一个问题：如果一组 Pod 对外提供服务（比方 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并拜访这个服务呢？
K8s 给出的解决方案是 Service。Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 Label 来筛选。
Service 有本人 IP，而且这个 IP 是不变的。客户端只须要拜访 Service 的 IP，K8s 则负责建设和保护 Service 与 Pod 的映射关系。无论后端 Pod 如何变动，对客户端不会有任何影响，因为 Service 没有变。
无状态服务个别应用什么形式进行部署？
Deployment 为 Pod 和 ReplicaSet 提供了一个 申明式定义方法，通常被用来部署无状态服务。
Deployment 的次要作用：
定义 Deployment 来创立 Pod 和 ReplicaSet 滚动降级和回滚利用扩容和索容暂停和持续。Deployment 不仅仅能够滚动更新，而且能够进行回滚，如果发现降级到 V2 版本后，服务不可用，能够迅速回滚到 V1 版本。
作者：玻璃樽
起源：dockone
