K8S学习

微服务、云、云原生的共同点：他们都是一种技术的称谓，他们出现不是自身发展出现的各种技术架构和逻辑，而是满足业务需求才出现的。所以要理解业务需求才能深刻的理解这些技术。利用云优势不是目标。已不是先有云优势，业务才上云。而是业务有了需求才有云这种技术和优势。

目标

业务目标/需求

1. 高效更新组件。在需求变化快，业务升级快时，需要频繁更新组件。
2. 高效协同开发。开发人员多，需要高效的协同开发。
3. 运行流畅。业务流量变化快，要满足高峰流量压力。
4. 降低成本。提高资源利用率。
5. 业务连续性。故障修复，高可用等。
6. 快速上线。新业务新功能上线要求快速上线。
7. 管理和运维简单。

微服务业务目标：

1. 解决高效更新组件。微服务就是减少各组件之间的耦合度，在业务需求变化快，业务升级快，需要频繁更新组件的场景中，可以单独更新组件。

云的业务目标：

1. 解决运行流畅。云资源的弹性扩展自动补充高并发时所需资源。
2. 解决降低成本。通过云的虚拟化可以使资源重复利用，提高资源利用率。
3. 解决快速上线。通过云可以快速提供底层资源，为开发测试，业务发布快速提供环境。

云原生的业务目标：

云原生的目标就是业务的目标，业务目标其实一直都不会改变的，改变的是在这些业务目标下不断出现新的技术来更好更高效的解决这些业务问题，满足业务目标。

所以云原生是结果，是业务目标需求推动的结果，这个结果又在不断进步。

早期只有虚拟化没有容器和K8s这些的时候，业务为了解决高可用高并发做集群架构，并利用云的资源自动伸缩能力来快速给集群提供底层资源。所以这时候的云原生就是指业务可以做成集群快速扩展的就是原原生。（业务状态就需要做持久化）

第二阶段就是微服务的阶段，业务在解决高可用高并发后，还要解决快速更新，高效协同等，就要对业务进行拆分，同时和高并发高可用低成本等一起催生了分布式系统的出现，这个时候在云中就集成了数据库，中间件等通用的分布式技术组件，所以这个时候的云原生就是业务做成分布式系统并直接使用云上的相关分布式组件。

第三阶段就是微服务编排和开发流水线等，业务在解决前面的问题后，还需要解决协同开发的问题；另外还是前面那些业务目标催生了新的技术容器和K8S，遇到高并发是要能快速扩展应用，之前的虚拟机方式太慢，于是出现了容器技术，快速复制和启动，谁来复制和启动？K8S来。

所以k8s解决什么问题？就是解决业务遇到高并发时自动伸缩容器，k8s关注对象就是容器；还有就是类似之前云对虚拟机的操作，部署，复制，启动，监控等等。

那么K8S怎么知道要操作那个容器？

通过yaml配置文件来知道要操作那个容器 ，yaml是k8s中所有对象的配置文件。对象分为资源pod对象，控制deployment对象，服务service对象等。在yaml文件中定义容器对象和对应的POD等，提交yaml后配置信息存在etcd数据库键值对中（不需要yaml文件了）。为什么用yaml文件形式不用界面形式等？因为可以方便生成和读取，方便用程序自动化操作。

K8s把容器存储在哪里？

k8s会把容器进行编队操作。编队形成逻辑pod概念，编队有啥目的？pod中的容器共享网络命名空间，存储卷，ip地址等。k8s自身的信息存储在ETCD中。容器已会存在etcd中吗？不会k8s并不直接存储和操作容器，而是由节点上的容器引擎来存储和操作容器，一个节点通常一个引擎，一个k8s集群中的pod通常用同一种引擎。一个POD跨多个节点，这个POD中就有多个引擎（不是多种还是一种）。yaml提交给k8s后，K8s会告诉容器引擎，容器引擎负责去拉取，启动等，容器会存在容器引擎的运行时内存中。

k8s怎么操作容器？

k8s的设计模式就是声明式API ，就是用户通过定义容器的期望状态交给k8s，k8s根据这个期望状态和规则去向容器引擎发起操作命令，用户不用关心怎么实现这些状态和怎么操作容器。

k8s中是通过控制器和调度器来操作容器的。控制器就是控制器对象（Deployment、StatefulSet、DaemonSet 等控制器），他有配置文件，指出该怎么操作，调度器就是按控制器的要求进行pod和容器的调度（节点选择，调度策略，调度决策，容错和恢复）。

K8s有哪些容器操作？

容器部署：

确保容器能够正确部署，并且能够在需要时自动扩展或收缩。

技术架构：使用 Deployment、StatefulSet、DaemonSet 等控制器的yaml配置来定义和管理容器的部署。定义规则包括自动创建、更新、删除容器，并与调度器协作以将其部署到集群中的合适节点上。

容器扩展：

根据流量和负载情况动态地增加或减少容器的数量，以满足应用程序的需求。

在horizontalpodautosacle（资源对象）配置文件中定义水平扩展规则，控制平面监控集群状态 （cpu内存使用状态等)，Hpa触发控制平面进行动作。在veticalpodautosacle中定义垂直扩展 ，通过Prometheus或grafana监控单个Pod状态，vpa触发控制平面进行动作。

K8s操作完了怎么进行监控和更新？

k8s的设计模式就是声明式API，K8s收到yaml中用户定义的期望和规则，那么就需要去对比期望和当前状态，才知道该怎么操作。

两种监控

针对整个集群的监控。K8s本身控制平面的监控是针对整个集群的，hpa,vpa规则。自定义可以使用 Prometheus + Grafana 进行整个集群的监控，关注整个集群的 CPU 使用率、内存使用率、节点健康状态等指标，通过 Grafana 的仪表盘展示整个集群的性能和健康状态。

针对单个POD和容器的监控。使用 Prometheus + Alertmanager 对单个 Pod 的 CPU 使用率进行监控，并定义报警规则。

K8S的关键组件

核心组件

1. API Server： 提供集群的 API 接口，用于管理集群中的各种资源和操作。

2. Scheduler： 负责将 Pod 调度到集群中的节点上，根据资源需求和约束条件进行智能调度。

3. Controller Manager： 包含多个控制器，负责监控集群中的各种资源和状态，并根据需要执行相应的操作和调整。

4. etcd： 分布式键值存储，用于存储集群的状态和配置信息，提供高可用性和一致性保证。

5. Cloud Controller Manager： 与云平台交互，管理与云平台相关的资源和操作，如负载均衡、存储、网络等。

6. 监控和日志组件： 包括 Prometheus、Grafana、Elasticsearch、Kibana 等，用于收集、存储和可视化集群的监控数据和日志信息。

流程例子

当用户提交一个 Deployment 对象到 Kubernetes 集群时，控制平面的 API Server 接收到该请求，并将其转发给 Controller Manager。在 Controller Manager 中，Deployment Controller 监听到该请求，并根据用户定义的配置信息创建相应的 ReplicaSet 对象。Scheduler 负责将该 ReplicaSet 中的 Pod 调度到集群中的合适节点上。一旦 Pod 被调度到节点上并成功启动，控制平面会监控 Pod 的运行状态，并根据需要执行相应的自愈操作，以确保应用程序能够稳定地运行。

• API Server： 接收并处理用户提交的 Deployment 对象请求，负责暴露 Kubernetes API。
• Controller Manager： 包括 Deployment Controller，负责监控集群状态并根据配置信息调整集群资源，如创建 ReplicaSet 对象等。
• Scheduler： 根据 Pod 的资源需求和调度策略，将 Pod 调度到集群中的合适节点上，确保资源的有效利用和负载均衡。
• ReplicaSet： 控制 Pod 的副本数量，确保在集群中按需创建和维护 Pod 的副本。
• Pod： 运行实际的容器实例，负责承载应用程序的运行。
• HorizontalPodAutoscaler (HPA)： 监测 Deployment 中 Pod 的 CPU 使用率或其他指标，根据预设的条件自动调整 Pod 的副本数量，以适应流量的变化。

对象

1. 核心对象（Core Objects）：

   • Pod
   • Service
   • Volume
   • Namespace
   • Secret
   • ConfigMap
   • PersistentVolume
   • PersistentVolumeClaim
   • Endpoint
   • Node

2. 控制器对象（Controller Objects）：

   • ReplicationController
   • ReplicaSet
   • Deployment
   • StatefulSet
   • DaemonSet
   • Job
   • CronJob

3. 网络对象（Networking Objects）：

   • Ingress
   • NetworkPolicy

4. 存储对象（Storage Objects）：

   • StorageClass
   • VolumeSnapshot
   • VolumeSnapshotClass

5. 策略对象（Policy Objects）：

   • PodSecurityPolicy
   • PodDisruptionBudget
   • ResourceQuota
   • LimitRange

6. 自动伸缩对象（Autoscaling Objects）：

   • HorizontalPodAutoscaler
   • VerticalPodAutoscaler

7. 监控对象（Monitoring Objects）：

   • PodMetrics
   • NodeMetrics

8. 扩展对象（Extensions Objects）：

   • IngressController
   • CustomResourceDefinition
   • MutatingWebhookConfiguration
   • ValidatingWebhookConfiguration

9. 状态对象（Status Objects）：

   • Event
   • ComponentStatus

10. 其他对象：

    • ServiceAccount
    • EndpointSlice
    • Lease