Docker痛点
如果想要将 Docker 应用于庞大的业务实现，是存在困难的，编排、管理和调度问题
Docker 虽好用，但面对强大的集群，成千上万的容器，显然支撑能力就不够了
K8S用来管理docker容器管理软件
K8s 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化
K8S有以下特点
可移植：支持公有云，私有云，混合云，多重云 multi-cloud
可扩展：模块化，插件化，可挂载，可组合
自动化：自动部署，自动重启，自动复制，自动伸缩/扩展
云和 K8s的关系<br>
云就是使用容器构建的一套服务集群网络，云由很多的大量容器构成。K8s 就是用来管理云中的容器
云架构分类
On-Premises（本地部署）<br>
IaaS（基础设施即服务）
PaaS（平台即服务）
SaaS（软件即服务）
云原生
概念：为了让应用程序（项目，服务软件）都运行在云上的解决方案，这样的方案叫做云原生
特点
容器化，所有服务都必须部署在容器中
微服务，Web 服务架构式服务架构
CI/CD
DevOps
K8s架构原理
概括来说 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 日志收集服务<br>
K8S核心组件
K8s 是用来管理容器，但是不直接操作容器，最小操作单元是 Pod （间接管理容器）
一个 Master 有一群 Node 节点与之对应
Master 节点不存储容器，只负责调度、网管、控制器、资源对象存储<br>
容器的存储在 Node 节点，容器是存储在 Pod 内部的
Pod 内部可以有一个容器，或者多个容器
Pod 也是一个容器，这个容器中装的是 Docker 创建的容器，Pod 用来封装容器的一个容器，Pod 是一个虚拟化分组
Pod 相当于独立主机，可以封装一个或者多个容器
Pod 有自己的 IP 地址、主机名，相当于一台独立沙箱环境
通常情况下，在服务部署时候，使用 Pod 来管理一组相关的服务。一个 Pod 中要么部署一个服务，要么部署一组有关系的服务
Kubelet 负责本地 Pod 的维护<br>
Kube-proxy 负责负载均衡，在多个 Pod 之间来做负载均衡
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 没有变。
Service 如何实现负载均衡
Service 资源对象包括如下三部分：<br>Pod IP：Pod 的 IP 地址<br>Node IP：物理机 IP 地址<br>Cluster IP：虚拟 IP ，是由 K8s 抽象出的 Service 对象，这个 Service 对象就是一个 VIP 的资源对象<br>Service VIP 更深入原理探讨
K8S应用场景<br>
自动化运维平台，创业型公司，中小型企业，使用 K8s 构建一套自动化运维平台，自动维护服务数量，保持服务永远和预期的数据保持一致性，让服务可以永远提供服务。这样最直接的好处就是降本增效
