应用部署方式演变
在部署应用程序的方式上，主要经历了三个时代：
传统部署
互联网早期，会直接将应用程序部署在物理机上
优点：简单，不需要其它技术的参与缺点：不能为应用程序定义资源使用边界，很难合理地分配计算资源，而且程序之间容易产生影响
虚拟化部署
可以在一台物理机上运行多个虚拟机，每个虚拟机都是独立的一个环境
优点：程序环境不会相互产生影响，提供了一定程度的安全性缺点：增加了操作系统，浪费了部分资源
容器化部署
与虚拟化类似，但是共享了操作系统
优点：可以保证每个容器拥有自己的文件系统、CPU、内存、进程空间等运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署
容器化部署方式给带来很多的便利，但是也会出现一些问题，比如说：
- 一个容器故障停机了，怎么样让另外一个容器立刻启动去替补停机的容器
- 当并发访问量变大的时候，怎么样做到横向扩展容器数量
这些容器管理的问题统称为容器编排问题，为了解决这些容器编排问题，就产生了一些容器编排的软件：
- Swarm：Docker自己的容器编排工具
- Mesos：Apache的一个资源统一管控的工具，需要和Marathon结合使用
- Kubernetes：Google开源的的容器编排工具
K8s简介
K8s全称叫做kubernetes。是一个全新的基于容器技术的分布式架构领先方案，是谷歌严格保密十几年的秘密武器----Borg系统的一个开源版本，于2014年9月发布第一个版本，2015年7月发布第一个正式版本。
kubernetes的本质是一组服务器集群，它可以在集群的每个节点上运行特定的程序，来对节点中的容器进行管理。目的是实现资源管理的自动化，主要提供了如下的主要功能：
- 自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
- 弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
- 服务发现：服务可以通过自动发现的形式找到它所依赖的服务
- 负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
- 版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
- 存储编排：可以根据容器自身的需求自动创建存储卷
K8s架构描述
一个K8s集群主要由控制（master）节点和工作（node）节点构成，每个节点上都会安装不同的组件。
master节点：
master节点是整个集群的控制平面，负责集群的决策、管理，其由几个组件构成：
- kube-apiserver：k8s集群资源操作的唯一入口，接收用户通过kubectl输入的命令，提供认证、授权、API注册和发现等机制
- etcd：分布式键值存储数据库，持久化保存集群所有状态数据（如 Pod、节点、配置等），简单点来说就是负责存储集群中各种资源对象的信息
- kube-scheduler：负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
- kube-controller-manager：负责维护集群的状态，比如程序部署安排，故障检测、自动扩展、滚动更新等，简单点来说就是确保集群实际状态与期望状态一致。
- cloud-controller-manager（可选）：对接云服务商（如 AWS、Azure、GCP），处理云平台相关逻辑。管理负载均衡器、存储卷、节点生命周期（如自动扩缩容）。仅在使用云服务时启用，本地环境无需此组件。
node节点：
node节点是整个集群的数据平台，负责为容器提供运行环境，简单点来说node节点就是负责干活的，其由几个节点构成：
- kubelet：管理Pod的生命周期和上报当前节点的状态。
- kube-proxy：负责Pod的访问路由及负载均衡实现
- 容器运行时环境：负责拉取镜像、运行容器。其中主要包含Docker、Containerd等组件，通过 CRI（Container Runtime Interface）与 kubelet 交互。
K8s单master架构
下图是一个K8s单master架构图，当一个master节点宕机之后，整个集群处于不可用的状态。
K8s多master架构
下图是一个K8s多master架构图，当一个master节点宕机之后，可以通过VIP飘移实现集群的高可用
K8s常用术语
OCI:
OCI（Open Container Initiative）是指开放容器标准，它是一个轻量级、开放的治理结构，致力于围绕容器格式和运行时创建开放的行业标准
通过支持OCI规范，Kubernetes可以与多种容器运行时兼容，这使得K8s在容器编排和管理方面更加灵活和强大。
CRI
CRI（Container Runtime Interface）是Kubernetes定义的一组与容器运行时进行交互的接口。
CRI是Kubernetes用来与容器运行时进行交互的标准接口。它定义了一套RPC（远程过程调用）API，这些API被用来管理容器的生命周期。
目前实现了CRI spec的Runtime有Docker Engine、containerd、CRI-O、Mirantis Container Runtime（Docker企业版）等。
已经弃用的有docker-shim
2020年k8s宣布弃用docker-shim，2022年k8s的1.24版本正式弃用docker-shim，这个时候如果容器使用docker的话，需要单独部署docker-shim。
所以在1.24版本之后推荐使用containerd做为容器运行时环境
CNI:
CNI（Container Network Interface）是一个规范和框架，它允许Kubernetes通过插件化的方式集成各种网络解决方案，以实现集群内部容器之间的网络通信。
支持的网络模式：Overlay Network，Underlay Network，flannel，calico，cannel，cilium