Kubernetes是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，简称 K8S。K8S的本质是一组服务器集群，可以在对应服务器集群的每个节点上运行程序，来对节点中的容器进行管理。类似Master-Work方式，每个服务器上安装特定的k8s组件，就可以形成集群，然后部署对应的应用即可。
（1）K8S常见功能
①服务发现和负载均衡
②存储编排
③自动部署和回滚
④自我修复
⑤密钥与配置管理
（2）K8S整体架构
K8S整体架构为Client-Server模型：
（1）控制节点【Master-Node】：负责集群管管理
（2）工作节点【Worker-Node】：负责为集群提供运行环境
控制节点Master-Node，负责集群的管理，控制节点包含如下组件
（1）apiserver【资源入口】
提供操作【k8s集群资源】的唯一入口，RESTful方式请求,并提供认证、授权、访问控制、API注册和发现等
（2）scheduler【计算】
负责资源的调度，按照预定的调度策略，【计算】将Pod调度到相应的Node节点进行应用部署
（3）controller-manager【管理】
控制器管理中心负责维护集群的状态，比如故障检测、滚动更新等，根据调度器的安排通知对应的节点创建pod。
（4）etcd【存储】
存储中心，是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库
工作节点Worker-Node，负责为集群提供运行环境。Node是Pod真正运行的主机，可以是物理机也可以是虚拟机, Node本质上不是K8S来创建的， K8S只是管理Node上的资源，为了管理Pod，每个Node节点上至少需要运行container runtime（Docker）、kubelet和kube-proxy服务，具体如下：
（1）kubelet
相当于主节点派到工作节点的一个代表，用于管理本机容器（相当于master节点的化身），负责维护容器的生命周期也负责Volume(CVI)和网络（CNI）的管理
①控制Pod生命周期
②控制CSI生命周期
③负责CNI创建和访问规则
（2）kube-proxy
负责为Service提供cluster内部的服务发现/网络代理/负载均衡等操作，为部署的应用程序提供访问入口，和apiserver是不一样的，后者用于操作k8s集群内部。
（3）kude-dns
作为服务发现机制的基本功能，在集群内需要能够通过服务名对服务进行访问，因此需要一个集群范围内的DNS服务来完成从服务名到ClusterIP的解析。
（4）Ingress Controller
①Ingress概述
Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改 yaml 然后创建/更新就行了。
②Ingress Controller
Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下，工作流程如下图：
Master指的是集群控制节点（相当于整个集群的指挥中心），在每个Kubernetes集群里都需要有一个Master来负责整个集群的管理和控制。
除了master，k8s集群中的其他机器被称为Node节点，Node节点才是kubernetes集群中的工作负载节点。每个Node节点都会被master分配一些工作负载（docker容器），node节点上的docker负责容器的运行。
Pod是一组容器, 在K8S中，最小的单位是Pod, 一个Pod可以包含多个容器，但通常情况下我们在每个Pod中仅使用一个容器。
Pod Controller控制器是管理pod的中间层，只需要告诉Pod控制器，想要创建多少个什么样的Pod，它会创建出满足条件的Pod并确保每一个Pod资源处于用户期望的目标状态。如果Pod在运行中出现故障，它会基于指定策略重新编排Pod
作用：通过它来实现对pod的管理，比如启动pod、停止pod、扩展pod的数量等等
类型：ReplicaSet、Deployment、Horizontal Pod Autoscaler、DaemonSet等
在k8s里面，每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失，Service (服务)就是用来解决这个问题的，提供对外服务的统一入口，用于为一组提供服务的Pod 抽象一个稳定的网络访问地址。
K8S提供了Label【标签】机制来为Pod进行分类，同一类pod会拥有相同的标签，Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改。
对应的资源打上标签后,可以使用标签选择器过滤指定的标签。
命名空间是在多个用户之间划分集群资源的一种方法（通过资源配额），**通过命名空间可以在一个物理集群上运行多个虚拟集群，用来隔离pod的运行环境，**同一个名字空间中的资源名称必须唯一，而不同名字空间之间则没有这个要求，NameSpace是不能嵌套的，每一个 Kubernetes 的资源都只能在一个NameSpace内。
Kubernetes 设计理念和功能其实就是一个类似 Linux 的分层架构，具体如下图所示：
（1）核心层：Kubernetes 最核心的功能，对外提供 API 构建高层的应用，对内提供插件式应用执行环境
（2）应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS 解析等）
（3）管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态 Provision 等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy 等）
（4）接口层：kubectl 命令行工具、客户端 SDK 以及集群联邦
（5）生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
| 组件作用 | 组件选型 | 备注 |
|---|---|---|
| 一致性和服务发现 | CoreDNS | |
| 远程调用服务 | gRPC | |
| 南北流量 | OpenRety | 七层反向代理 |
| 服务网格 | Istio | |
| API网关 | trafik | |
| 存储 | Ceph | |
| 云原生网络 | flannel | |
| 容器运行时 | docker | |
| 容器注册 | dockerhub【公网】、HARBOR【私网】 | |
| 权限管理 | RBAC | |
| 监控 | prometheus + Grafana | |
| 日志 | beats |
