4.K8S架构
4.1 声明式系统VS命令式系统
先来看下声明式系统和命令式系统的对比
看一下上面的图片
左边空调遥控器，它是属于声明式系统，
例如：我们把目标温度设置好，不管他过程怎么调节，最终结果达到25度就好
右边这个是电视遥控器，它属于命令式，它有很多按钮，
例如：我们点了1频道，电视要立刻切换到1频道，
总结一下：
声明式系统：关注目标-“做什么”
在软件工程领域，声明式系统指程序代码描述系统应 该做什么而不是怎么做。
仅限于描述要达到什么目的， 如何达到目的交给系统。
命令式系统：关注过程- “如何做”
在软件工程领域，命令式系统是写出解决某个问 题，完成某个任务，或者达到某个目标的的明确步 骤。
此方法明确写出系统应该执行某指令，并且期待系统返回期望结果。
4.2 k8s-声明式系统
Kubernetes 的所有管理能力构建在对象抽象的基础上，
核心对象包括：
• Node：计算节点的抽象，用来描述计算节点的资源抽象，健康状态等
• Namespace：资源隔离的基本单位，可以简单理解为文件系统中的目录结构
• Ingress：是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP
• Service：服务如何将应用发布成服务，本质上是负载均衡和域名服务的声明
• Pod：用来描述应用实例，包括镜像地址，资源需求等。 Kubernetes 中最核心的对象，也是打通应用和基础架构的秘密武器
4.2.1 声明方式-yaml
k8s是声明式系统，那他是如何做到的呢？他是通过自定义yaml，实现声明。简单看下yaml中字段的一些解释。
Apiversion：定义api版本标签
Kind：定义资源的类型、角色，其中有常用的这几种(deployment、service、Ingress、Job、Map)
Metadata：定义资源的元数据信息，比如资源名称，namespace,标签等
Spec：定义资源需要的参数属性，比如副本数量，标签选择器，业务版本，是否需要容器，容器镜像版本，容器启动名称，启动策略，硬件资源限制，等等，都是通过spec的子项进行定义
4.3 Kubernetes的基本概念
1.集群
Kubernetes集群是由多个节点组成的集合，这些节点可以在同一物理机器上，也可以在不同的物理机器上。
集群由Master节点和Worker节点组成。Master节点用于管理整个集群，而Worker节点用于托管应用程序的容器。集群中的每个节点都有一个代理程序（kubelet），它与Master节点进行通信，以管理容器。
2.节点
Kubernetes节点是集群中的计算机，可以是物理计算机或虚拟机。节点可以是Master节点或Worker节点。
Master节点负责管理整个集群，而Worker节点负责托管应用程序的容器。
3.容器
Kubernetes容器是一种轻量级的虚拟化技术，它可以将应用程序及其依赖项打包到一个可移植的镜像中，并在运行时在任何地方运行。
Docker是一种常用的容器技术，Kubernetes也支持其他容器技术。
4.Pod
Kubernetes Pod是一个或多个紧密耦合的容器的最小部署单元。
Pod包含一个或多个应用程序容器，这些容器共享相同的网络和存储资源，并可以通过本地进程间通信（IPC）和共享文件系统进行通信。
Pod还可以包含一个或多个初始化容器，这些容器在应用程序容器之前运行，以准备Pod的运行环境。
通俗一点解释：
在一个真正的操作系统里，进程并不是“孤苦伶仃”地独自运行的，而是以进程组的方式，“有原则地”组织在一起，如下图：
前面我们已经知道容器的本质是进程，k8s就是操作系统
而k8s所做的，其实就是将“进程组”的概念映射到了容器技术中,就产生了pod
所以说，pod是一个逻辑概念。他是一组共享了某些资源的容器。
具体的说：Pod 里的所有容器，共享的是同一个 Network Namespace，并且可以声明共享同一个 Volume。
这些共享容器，通过 Join Network Namespace 的方式，与 Infra 容器关联在一起。
这样的组织关系整体，叫做pod
也可以理解为，Pod 扮演的是传统部署环境里“虚拟机”的角色。
这样的设计，是为了使用户从传统环境（虚拟机环境）向 Kubernetes（容器环境）的迁移，更加平滑。
5.Service
Kubernetes Service是一种抽象，用于定义Pod的逻辑集合，这些Pod可以作为单个单位进行访问。Service提供了一个稳定的网络终结点，以便其他应用程序可以通过它来访问Pod。Service还可以定义负载均衡规则，以将流量分配到多个Pod之间。
举个简单的例子
比如 前端Web 应用与后端服务之间的访问关系，像这样的两个应用，往往故意不部署在同一台机器上，这样即使 Web 应用所在的机器宕机了，后端服务也完全不受影响。
我们知道，对于一个容器来说，它的 IP 地址等信息不是固定的，后端每次发布ip都会改变，那么 Web 应用又怎么找到后端服务容器的 Pod 呢？
所以，Kubernetes 项目的做法是给 Pod 绑定一个 Service 服务，而 Service 服务声明的 IP 地址等信息是“终生不变”的。
因此：这个 Service 服务的主要作用，就是作为 Pod 的代理入口，从而代替 Pod 对外暴露一个固定的网络地址。这样，对于 Web 应用的 Pod 来说，它需要关心的就是后端服务 Pod 的 Service 信息。
6.Deployment
Kubernetes Deployment是一种控制器，它可以自动化容器的部署和更新。Deployment使用Pod模板定义应用程序容器的规范，然后创建和管理Pod的副本。如果Pod失败或被删除，Deployment将自动创建一个新的Pod以替换它。
问题：
通过上面对象的介绍，现在我们应该已经稍微理解了一下这几个对象，那现在来思考下这个问题，“K8S如何通过对象组合完成业务描述？”他们之间是怎么做的呢？
在 k8s项目中，所推崇的使用方法是：
首先，通过一个“编排对象”，比如 Pod、Job、 等，来描述你试图管理的应用；
然后，再为它定义一些“服务对象”，比如 Service、Secret、ingress。这些对象，会负责具体的平台级功能。
这种使用方法，就是所谓的“声明式 API”。
这种 API 对应的“编排对象”和“服务对象”，都是 k8s项目中的 API 对象（API Object）
4.4 K8S核心组件
k8s项目的架构，由 Master 和 Node 两种节点组成，这两种角色分别对应着控制节点和计算节点
4.4.1 kube-apiserver
kube-apiserver：kube-apiserver是k8s集群的控制面板，提供了RESTful API来管理集群状态和配置。它是k8s中的核心组件之一，所有其他组件都与kube-apiserver进行通信。kube-apiserver是k8s的面向用户的接口，可以使用kubectl等工具与其进行交互。
4.4.2 kube-scheduler
kube-scheduler：kube-scheduler是k8s的调度器，负责将Pods分配到可用的节点上。kube-scheduler使用节点资源和Pods的需求来进行调度决策。kube-scheduler还支持自定义调度策略，以满足特定的业务需求。
4.4.3 kube-controller-manager
kube-controller-manager：kube-controller-manager是k8s的控制器，负责监视集群状态，并确保集群中的对象处于所需的状态。kube-controller-manager包括多个控制器，如Replication Controller和Endpoint Controller，它们负责管理ReplicaSets和Endpoints等对象。
4.4.4 etcd
etcd：etcd是一个高可用性的键值存储系统，用于存储k8s集群的所有数据。etcd可以存储集群配置、Pods和Services等对象的状态。etcd是一个分布式系统，可以通过多个节点实现高可用性
4.4.5 kubelet
kubelet：kubelet是k8s节点上的代理，负责管理节点上的Pods。kubelet与kube-apiserver通信，获取需要在节点上运行的Pods的信息，并确保Pods处于运行状态。kubelet还负责监视Pods的健康状况，并在必要时重新启动它们。
4.4.6 kube-proxy
kube-proxy：kube-proxy是k8s的网络代理，负责在集群内部进行负载均衡和服务发现。kube-proxy可以将Pods暴露为Kubernetes Services，并使用IPVS或iptables等机制进行负载均衡。
4.4.7 docker/Container Runtime
docker/Container Runtime：Worker Node的运行环境，负责镜像管理以及 Pod 和容器的真正运行
总结一下：
其中，控制节点，即 Master 节点，由4个紧密协作的独立组件组合而成，它们分别是：
负责 API 服务的 kube-apiserver、负责调度的 kube-scheduler、负责容器编排的 kube-controller-manager。整个集群的持久化数据，则由 kube-apiserver 处理后保存在 Etcd 中。
而计算节点上最核心的部分，则是一个叫作 kubelet 的组件。
在 k8s项目中，kubelet 主要负责同容器运行时（比如 Docker 项目）打交道。而这个交互所依赖的，是一个称作 CRI（Container Runtime Interface）的远程调用接口，这个接口定义了容器运行时的各项核心操作比如：启动一个容器需要的所有参数。
这也是为什么，Kubernetes 项目并不关心你部署的是什么容器运行时、使用的什么技术实现，只要你的这个容器运行时能够运行标准的容器镜像，它就可以通过实现 CRI 接入到 Kubernetes 项目当中。
4.5 k8s能力展示
4.5.1 资源调度
一句话描述就是把pod放到合适的node上，但是这个合适，需要满足这四个方面：
- 首先要满足 pod 的资源要求
- 其次要满足 pod 的一些特殊关系的要求
- 再次要满足 node 的一些限制条件的要求
- 最后还要做到整个集群资源的合理利用
当然，这些判断都是k8s自己去控制的，我们只需要用声明的方式，把目标pod描述清楚就可以了。下面是简单的动画演示：
4.5.2 水平伸缩
Kubernetes具备HPA自动扩容的能力，目前支持按照CPU指标和用户自定义（比如TPS或QPS）达到某个数量级触发自动扩容，当请求高峰过去之后，pod可以恢复到原来的水平。如下图所示检测到白色节点负载过高，自动把服务复制两份，分发到其它节点运行：
4.5.3 故障恢复
Controller-Manager组件，会时刻检测，当然也包括故障检测，当他检测到某一个节点不可用了，他会自动把pod放到正常节点上去运行。就像下图这样
5.总结
在使用Kubernetes时，需要熟悉Kubernetes的核心概念和机制，并学习如何使用API和CLI工具进行操作。
同时，还需要掌握Docker等容器技术，以便将应用程序打包成容器镜像，并部署Kubernetes集群中。
Kubernetes是一种强大的容器编排平台，它可以帮助开发者更轻松地管理容器化应用程序。
学习之路也是任重而道远，大家一起加油吧！！
