背景
为避免一学就会、一用就废，这里做下K8S的学习笔记
基础组件
Pod
Pod是K8s中最小的可部署和调度单元，可以理解为一个逻辑主机。Pod中通常只运行一个容器，但特殊情况也可以运行多个容器，如一个业务应用容器，一个日志采集容器，两者共享一个Pod（单Pod内部，网络和存储是共享的）
Service
Pod对外部访问而言不稳定，如一个微服务Pod伸缩为多个Pod，或一个Pod挂掉，又重新生成，为了让外部能稳定访问 ，因此出现Service。Service不是一个单独的进程，不存在单点问题。因此实现应用的服务化。
Ingress
生产环境，外部访问K8S内的应用，一般通过域名访问，因此使用Ingress来实现这一点。同时，Ingress还能实现负载均衡，SSL认证等网关的基本功能。它本质也是个Pod，落到实现层面，就是Nginx。
ConfigMap
业务应用和配置，应分开放置，否则简单改个配置就必须换镜像并生成新Pod，成本太大，因此用ConfigMap解决此问题。配置存ConfigMap中，修改配置，最多是重建Pod，但不用重新编译镜像
Secret + SA + User + C.Role + Binding
Secret作用同ConfigMap，只是相对更安全，用来放敏感信息如密码。但它本身安全性不高，必须配合RBAC一起才能提升安全性。这里的SA、User、和C.Role，就是用来实现这个RBAC的具体组件。被权限保护的资源是这里Secret中的内容，尝试申请权限的是SA（应用）或者User。资源的权限挂载到角色Role之上。通过Binding实现这两者的挂钩
Volumes
当Pod被销毁，Pod内的数据会丢失，这对于数据库等有状态的应用不可接受，因此出现Volumes，用来将Pod中需要单独持久化的数据挂载到外部卷
Deployment
业务Pod节点（无状态节点）在单Node中存在单点问题，无法高可用，因此要多节点部署，动态管理Pod集群，因此出现deployment组件来解决此问题。通过该组件实现副本控制、滚动更新、自动扩缩容
StatefulSet
类似Deployment，但主要用来管理数据库这类有状态的节点，为其提供高可用能力。但StatefulSet本身还是比价麻烦的，实际生产环境，可以选择数据库等有状态组件独立于K8S之外部署
架构
K8S是典型的Master-Worker架构
Worker Node
Kubelet
一般一个节点安装一个，是每个Node上的"节点管家"。它对外，对接ApiServer，是集群控制面和本机之间的桥梁，如接收ApiServer传过来的Pod管理请求或上报Pod状态给ApiServer。对内，负责管理和维护每个节点上的pod（具体通过调用容器运行时的接口，来执行具体的管理操作）
Kube-Proxy
一般一个节点安装一个，是每个Node内的"网络管家"。为Pod对象提供网络代理和负载均衡服务。和Ingress不同，Ingress是集群级别的，工作在网络协议的第七层，关心用户请求应该转发到哪个Service;而Kube-Proxy是节点级别的，工作在网络协议的第四层，关心进入到当前节点某Service的请求，应该转发给哪个Pod。
Container-Runtime
负责拉取镜像、创建容器、启动或者停止容器。如Docker Engine是docker的容器运行时，新版本Docker改用Containerd作为容器运行时。一般一个节点上装一个container-runtime即可
Master Node
ApiServer
K8S控制平面的核心网关，是整个集群的唯一入口。所有组件想要读写集群状态，都必须经过它。它的职责：
1、暴露K8S API
2、处理并持久化状态到ETCD
3、充当各组件的通信中枢
4、操作鉴权
Scheduler
监控集群中所有节点资源使用情况，根据调度策略，将Pod调度到合适的节点上运行（资源空闲的节点）
Controller Manager
管理集群中，各种资源对象的状态。如集群中某Pod故障，需要该组件及时检测到该故障，并进行处理（重启或新增Pod等）
Etcd
集群的数据存储中心，存储的内容包括：
1、集群中各种资源的实时状态，包括Node、Pod、Ingress等资源的状态
2、集群中其他的配置信息
部署
MiniKube
轻量级K8S发行版，可在本地计算机上创建虚拟机，并部署仅包含一个节点的简单集群。其他轻量级发行版，还有K3S、K3D、Kind等
若是生产环境，建议至少3个Mater节点，3个Worker节点，以保证高可用。
运维
可视化运维工具：portainer，其本身就是一个容器化的应用