Kubernetes 简述

Kubernetes 简述
1、功能

1.1 主要功能

Kubernetes 是一个开源的容器编排平台，它提供了一系列功能来管理和部署容器化应用程序。以下是 Kubernetes 的一些主要功能：
1. 容器编排：Kubernetes 可以自动管理容器的部署、扩展和收缩，以满足应用程序的需求。它可以根据容器的资源需求和拓扑结构自动创建和管理容器集群。
2. 服务发现和负载均衡：Kubernetes 提供了服务发现和负载均衡功能，可以将多个容器组合成一个服务，并通过内置的负载均衡器将请求分发到容器。
3. 自动部署和回滚：Kubernetes 可以自动部署容器镜像，并在出现问题时进行回滚。它支持滚动更新，可以逐步更新容器，以减少停机时间。
4. 资源管理：Kubernetes 可以自动管理容器所需的资源，例如 CPU 和内存。它可以根据容器的需求动态分配资源，以确保容器具有足够的资源来运行。
5. 自动扩展和收缩：Kubernetes 可以根据应用程序的负载自动扩展和收缩容器集群。它可以自动创建新的容器实例以处理增加的负载，并在负载下降时自动删除容器实例以节省资源。
6. 自我修复：Kubernetes 具有自我修复功能，可以自动检测和修复容器集群中的问题，例如容器故障或资源不足。
7. 存储管理：Kubernetes 可以自动管理存储，例如基于容器的存储卷和有状态应用程序的数据存储。
8. 安全：Kubernetes 提供了一系列安全功能，例如访问控制、加密和身份验证，以保护容器化应用程序的安全性。
9. 日志和监控：Kubernetes 提供了内置的日志和监控功能，可以收集和分析容器的日志，并提供应用程序的监控指标。
10. 插件化：Kubernetes 是一个可扩展的平台，支持通过插件扩展功能。开发人员可以编写自己的 Kubernetes 插件来满足特定的需求。
总之，Kubernetes 是一个强大的容器编排平台，提供了一系列功能来管理和部署容器化应用程序。它可以简化容器化应用程序的部署、管理和扩展，提高应用程序的可靠性、可扩展性和安全性。

1.2 概念映射-个人观点

pod、service和spring cloud类比
- pod：服务实例。
  - 类比为微服务中的一个服务节点。
- service：服务实例（Pod）的逻辑集合和访问这个集合的策略。
  - 服务发现：Service通过Label和Selector机制来实现服务发现，这可以类比为Spring Cloud中的服务发现机制。
  - 负载均衡：Service通过内置的负载均衡器和支持外部负载均衡器实现，这可以类比为Spring Cloud中的负载均衡策略（例如，Ribbon）。
Kubernetes与spring cloud区别

Kubernetes与spring cloud存在功能重叠，以下只说spring cloud不具备的功能。
- 语言无关性：Kubernetes是一个多语言平台，能够运行云本地和传统的容器化应用程序，而Spring Cloud主要是为JVM语言设计的。
- 更广泛的MSA问题：Kubernetes解决了更广泛的MSA问题，提供了更多的功能，如设置资源限制、RBAC、应用程序生命周期管理等。
- 自动扩展和自我修复：Kubernetes可以自动伸缩，而Spring Cloud不具备这个功能。
2、容器编排

Kubernetes容器编排主要是通过各种控制器（Controller）和调度器（Scheduler）来实现的。
1. 部署控制器（Deployment Controller）：负责管理应用程序的部署，包括扩大、缩小和滚动更新等操作。它通过操纵ReplicaSet对象（而不是直接操作Pod对象）来实现这些操作，ReplicaSet通过“控制器模式”保证系统中Pod的个数永远等于指定的个数，Deployment Controller同样通过“控制器模式”来操作ReplicaSet的个数和属性，进而实现水平扩展/收缩和滚动更新这两个编排动作。
2. 服务控制器（Service Controller）：负责实现服务发现和负载均衡等功能。Kubernetes中的服务发现机制是通过kube-dns来实现的，kube-dns可以解析出Service的cluster IP，从而实现服务的自动发现。Service Controller通过标签选择器来选取服务后端，再结合kube-proxy来实现负载均衡功能。
此外，Kubernetes还提供了各种调度器（Scheduler），如Default Scheduler、In-tree Cloud Provider Scheduler和Out-of-tree Cloud Provider Scheduler等，它们负责在集群中调度和分配资源，以及在运行时根据Pod的亲和性和反亲和性规则将Pod调度到合适的节点上。

2.1 ReplicaSet对象
- 选择器（Selector）：用于识别和选择Pod，确保ReplicaSet控制器可以找到并管理它们。
- 副本数（Replicas）：用于设置期望的Pod副本数量，确保用户服务能够正常运行。
- 就绪检查（Readiness Probe）：用于检查Pod是否准备好接收服务请求，确保用户服务能够正常运行。
- 回退策略（Rollback Strategy）：用于配置回退策略，确保用户服务的稳定性和可用性。
- 升级策略（Upgrade Strategy）：用于配置升级策略，确保用户服务的稳定性和可用性。
- 自动缩放（Autoscaling）：用于配置自动缩放功能，根据负载情况自动调整用户服务实例的数量。
2.2 pod

2.2.1 问题-Kubernetes如何判断应用程序存活的？

Kubernetes通过探针liveness probe来判断应用程序是否存活。下面我们通过介绍pod来了解探针。

2.2.2 Pod状态

Pod是Kubernetes中最小的部署单元，它包含一个或多个容器。Pod的状态可以是以下几种1：
- Pending：Pod的YAML文件已经提交给Kubernetes，API对象已经被创建并保存在Etcd中，但Pod还没有被调度成功，这通常是由于下载镜像慢或其他原因造成的。
- Running：Pod已经绑定到一个节点上，并且已经创建了所有容器，至少有一个容器正在运行或正在启动。
- Succeeded：Pod中的所有容器都已经成功终止并退出，这种情况在运行一次性任务时最为常见。
- Failed：Pod中所有的容器均已经终止，且至少有一个容器已经在故障中终止。
- Unknown：由于某种原因，apiserver无法获取到Pod的状态，通常是由于Master与Pod所在的主机失去连接造成的。
2.2.3 Pod的重启策略

Pod的重启策略是指当Pod内的某个容器异常退出或健康检查失败时，kubelet根据设定的策略自动重启该容器。

Pod的重启策略包括以下三种：
- Always：当容器失效时，由kubelet自动重启该容器。如果pod的restartpolicy没有设置那么默认值是Always。
- OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。
- Never：不论容器运行状态如何，kubelet都不会重启该容器。
2.2.4 Kubernetes的探针类型

Kubernetes的探针类型有三种，分别如下：
1. 启动探针（Startup Probe）：用于判断容器内应用程序是否启动，如果配置了startupProbe，就会先禁止其他的探针，直到它成功为止，成功后将不再进行探测。
2. 就绪探针（Readiness Probe）：判断容器是否已经就绪，若未就绪，容器将会处于未就绪，未就绪的容器，不会进行流量的调度。
3. 存活探针（Liveness Probe）：判断容器内的应用程序是否正常，若不正常，根据Pod的restartPolicy重启策略操作。
2.2.4.1 Kubernetes的探针使用方法

Kubernetes的三种探针都支持三种探测方法。
- ExecAction：在容器中执行指定的命令，如果执行成功，退出码为0则探测成功。
- HTTPGetAction：通过容器的IP地址、端口号及路径调用HTTP Get方法，如果响应的状态码大于等于200且小于400，则认为容器健康。
- TCPSocketAction：通过容器的 IP 地址和端口号执行 TCP 检查，如果能够建立 TCP 连接，则表明容器健康。
探针探测结果有以下值
- Success表示通过检测。
- Failure表示未通过检测。
- Unknown表示检测没有正常进行。
2.2.4.2 httpGet-示例

好的，以下是一个使用httpGet探测方式的Kubernetes ReadinessProbe的配置示例：
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: my-image
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
              httpHeaders:
                - name: User-Agent
                  value: curl/7.64.1
              initialDelaySeconds: 10
              timeoutSeconds: 1```
```
在上面的示例中，我们定义了一个名为my-app的Deployment资源，其中包含了一个名为my-container的容器。容器的端口号为8080，并且配置了一个ReadinessProbe来探测容器的状态。

在ReadinessProbe的配置中，我们使用了httpGet探测方式。具体来说，我们指定了一个路径为/healthz，端口号为8080的HTTP Get请求来进行探测。我们还指定了User-Agent为curl/7.64.1，初始延迟时间为10秒，超时时间为1秒。如果HTTP Get请求返回的状态码在200-399之间，则表示探测成功，否则表示失败。

3、服务发现和负载均衡

Kubernetes的服务发现和负载均衡主要通过以下方式实现：
- Service。Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。借助Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service通过标签来选取服务后端，一般配合Replication Controller或者Deployment来保证后端容器的正常运行1。
Service有三种类型：
- ClusterIP。这是默认类型，自动分配一个仅cluster内部可以访问的虚拟IP。
- NodePort。在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过:NodePort来访问该服务。
- LoadBalancer。在NodePort的基础上，借助cloud provider创建一个外部的负载均衡器，并将请求转发到:NodePort。
另外，也可以讲已有的服务以Service的形式加入到Kubernetes集群中来，只需要在创建Service的时候不指定Label selector，而是在Service创建好后手动为其添加endpoint1。
- kube-proxy。运行在每个node上的kube-proxy进程其实就是一个智能的软件负载均衡器，它负责把service的请求转发到后端的某个pod实例。
- kube-dns。kube-dns可以解决Service的发现问题，即把服务名解析为cluster IP。
4、自动部署和回滚

在Kubernetes中，应用升级策略主要有以下几种
- 滚动更新（Rolling Update）。最常见的更新策略，允许逐步替换旧版本的Pod实例，确保应用程序在更新过程中保持可用。适用于无状态应用，并且可以指定更新速率和同时更新的Pod数量。
- 蓝绿部署（Blue/Green Deployment）。在新旧版本之间进行切换的策略，先部署一个全新的版本（绿色），然后在切换时将流量从旧版本（蓝色）切换到新版本。这种策略允许在部署过程中立即回滚到旧版本，以应对意外问题。
下面主要说一下最常用的滚动更新

滚动更新

Kubernetes滚动更新流程是指对部署中的Pod进行逐步替换，以达到平滑更新的目的。

更新过程
1. 创建一个新版本的Pod副本，并将其加入到Service或Ingress中的后端。
2. 逐步调整副本数量，同时逐步减少旧版本Pod的数量，达到平滑替换的效果。
3. 在每次调整过程中，容器创建和销毁完成后会进行一段时间的健康检查，确保新版本Pod可以正常工作。
4. 重复步骤2和步骤3，直到所有旧版本的Pod都被替换为新版本。
示例
1. 首先，当修改了 Deployment 里的 Pod 定义之后，Deployment Controller 会使用这个修改后的 Pod 模板，创建一个新的 ReplicaSet(v2)，这个新的 ReplicaSet 的初始 Pod 副本数是：0。
2. Deployment Controller 开始将这个新的 ReplicaSet-(v2)所控制的 Pod 副本数从 0 个变成 1 个，即：“水平扩展”出一个副本。
3. Deployment Controller 又将旧的 ReplicaSet-(v1)所控制的旧 Pod 副本数减少一个，即：“水平收缩”成两个副本。
4. 如此交替进行，新 ReplicaSet 管理的 Pod 副本数，从 0 个变成 1 个，再变成 2 个，最后变成 3 个。
5. 而旧的 ReplicaSet 管理的 Pod 副本数则从 3 个变成 2 个，再变成 1 个，最后变成 0 个。
这样，就完成了这一组 Pod 的版本升级过程。
- Deployment 的控制器，实际上控制的是 ReplicaSet 的数目，以及每个 ReplicaSet 的属性。
- 一个应用的版本，对应的正是一个 ReplicaSet；这个版本应用的 Pod 数量，则由 ReplicaSet 通过它自己的控制器（ReplicaSet Controller）来保证。
- 通过这样的多个 ReplicaSet 对象，Kubernetes 项目就实现了对多个“应用版本”的描述。
        像这样，将一个集群中正在运行的多个 Pod 版本，交替地逐一升级的过程，就是“滚动更新”。

        使用 Deployment 进行滚动更新是一种方便而可靠的方式，可以确保服务的连续性和可用性。在更新过程中，需要密切监控服务的性能和可用性，并及时采取措施来解决任何问题。

        总的来说，Kubernetes 提供了一系列功能和特性，以帮助用户更好地管理应用程序和服务的更新和部署。这些功能可以根据用户的需求进行配置和使用。

Kubernetes滚动更新问题

要停止的pod正在处理程序，如何处理？

        在Kubernetes中，滚动更新通常是通过逐步替换旧版本的Pod来升级服务。如果一个正在处理的Pod需要被停止，但该Pod正在处理的程序还没有完成，可能会导致数据丢失或者服务中断。

为了处理这种情况，Kubernetes提供了几种策略来控制滚动更新的过程：
1. 优雅地关闭：在滚动更新过程中，Kubernetes允许为正在运行的Pod提供一段优雅关闭的时间。在这段时间内，Pod将被标记为正在关闭，并且不会立即被替换。这样可以给正在运行的程序足够的时间来完成其工作并清理资源。优雅关闭的时间可以通过terminationGracePeriodSeconds参数进行配置。
2. 就地升级：就地升级是指在滚动更新过程中，新版本的Pod直接替换旧版本的Pod，而不需要将旧版本的Pod完全关闭。就地升级适用于那些可以快速启动并恢复的服务。如果服务需要较长时间才能完成启动过程，就地升级可能会导致服务中断。
3. 缩容回退：在某些情况下，滚动更新可能会导致某些Pod启动失败或者出现故障。为了应对这种情况，Kubernetes允许配置回退策略，以便在更新失败时自动回退到旧版本。回退策略可以通过RollingUpdateStrategy参数进行配置。
        根据具体的需求和服务特性，你可以选择适合的滚动更新策略来处理正在处理的Pod需要被停止的情况。确保在滚动更新过程中，为Pod提供足够的优雅关闭时间或使用就地升级策略，以确保服务的可用性和数据的一致性。

新版pod替换旧版pod，是两个版本同时存在，都是启动状态吗？

        Kubernetes滚动更新时，新旧两个版本的Pod不会同时存在。

        滚动更新时，Kubernetes会逐步将旧版本Pod替换为新版本Pod，这个过程是逐步进行的，而不是一次性完成的。在替换过程中，旧版本Pod会被逐步停用和删除，同时新版本Pod会被逐步创建和启动。因此，在滚动更新过程中，只有新版本Pod是处于启动状态的，而旧版本Pod会被逐步停用并最终被删除。

新版pod替换旧版pod，新版pod是不是还不可用，要有一个启动过程？

        Kubernetes滚动更新时，新版Pod不是立即可用，而是需要经过一段时间的启动和健康检查过程 。在每次调整过程中，容器创建和销毁完成后会进行一段时间的健康检查，确保新版本Pod可以正常工作。如果新版本Pod没有通过健康检查，那么滚动更新会失败，Kubernetes会启动回滚更新，把Pod版本回退到旧版本。

Kubernetes滚动更新过程，新旧两版接口会同时存在吗？

        在滚动更新过程中，只有新版本Pod的接口是存在的，而旧版本Pod的接口会逐渐被停用并最终被删除。在这个过程中，如果客户端仍然使用旧版本的接口，而新版本的Pod还没有完全替换旧版本的Pod，那么客户端可能会遇到服务不可用的错误。

        滚动更新时，Kubernetes会逐步将旧版本Pod替换为新版本Pod。这个过程是逐步进行的，每次只更新一部分，因此在这个过程中会出现新旧Pod同时存在的时刻。但是，由于滚动更新是逐步进行的，因此在这个过程中只有新版本Pod的接口是可用的，而旧版本Pod的接口会逐渐被停用并最终被删除。

新版接口刚升级一个节点提供服务，是否有服务器被压垮的风险？

存在服务器被压垮的风险。

微服务升级
- 按功能模块分批次升级。
  - 一个功能模块一个批次，如用户，商品两个功能模块，第一个批次升级用户，用户升级完后，第二个批次升级商品。
举例

前提
- 功能模块：用户，商品，营销，订单，客服。
- 每个功能模块部署了3个节点。
1. 确定发布计划：
  - 重要性和影响力分析：
    
    用户模块：非常重要，影响范围广
    商品模块：比较重要，影响范围较小
    营销模块：比较重要，影响范围中等
    订单模块：比较重要，影响范围较大
    客服模块：比较重要，影响范围较小
  - 发布计划：
    
    分批次发布：分为5个批次，每个批次发布一个模块的新版本
2. 确定批次数量：每个模块有3个节点，因此需要发布5个批次，每个批次发布一个模块的一个节点。
3. 创建Deployment：在Kubernetes中创建5个Deployment，分别用于管理每个功能模块的微服务生命周期。以下是创建用户模块Deployment的示例命令：
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-microservice
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-microservice
  template:
    metadata:
      labels:
        app: user-microservice
    spec:
      containers:
        - name: user-microservice
          image: user-microservice:v1.0
          ports:
            - containerPort: 8080
```
4. 定义Pod模板：在每个Deployment中定义Pod的模板，包括微服务的镜像、配置文件等。在Pod模板中，我们需要指定容器的镜像、环境变量、端口等。以下是示例Pod模板：
```
apiVersion: v1
kind: PodTemplate
metadata:
  name: user-microservice-template
spec:
  template:
    metadata:
      labels:
        app: user-microservice
    spec:
      containers:
        - name: user-microservice
          image: user-microservice:v1.0
          env:
            - name: USER_DB_HOST
              value: mydatabasehost.example.com   # 用户数据库的主机名和域名
          ports:
            - containerPort: 8080
```
5. 定义滚动策略：在每个Deployment中定义滚动策略，包括滚动方式和批次数量。在本例中，采用滚动更新方式，每次更新一个节点。以下是滚动策略的示例配置：
```
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: user-microservice
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-microservice
  strategy:
    rollingUpdate:
      maxUnavailable: 1   # 每次只更新一个节点（即最多有一个节点不可用）
      maxSurge: 1         # 最大增加一个节点（即最多增加一个节点）和重启机制配置信息如下：maxUnavailable：表示每次升级可以有多少节点无法访问（1表示每次只升级一个节点） maxSurge：表示每次升级可以有多少节点同时启动新的Pod（也就是新增节点数），这个数值应该与maxUnavailable保持一定的差值（例如1）以避免新旧Pod同时运行出现问题。如上面描述，maxUnavailable为1，maxSurge也为1，表示每次升级只有一个节点无法访问，同时新增一个节点。如果升级过程中出现问题，可以回滚到上一个版本。回滚操作可以通过执行kubectl rollout undo命令来实现。例如，要回滚用户模块的部署，可以执行以下命令：kubectl rollout undo deployment/user-microservice。
```
5、资源管理

Kubernetes对资源的管理主要通过资源请求（requests）和资源限制（limits）来实现，具体如下：
- 资源请求（requests）。这是Kubernetes中一种基本资源管理方式，用于指定应用运行所需的资源下限。如果没有资源请求，那么应用可能无法运行。在Kubernetes中，资源请求通常包括CPU和内存等资源。
- 资源限制（limits）。这是Kubernetes中另一种资源管理方式，用于限制Pod或容器使用的资源量。通过设置资源限制，可以防止Pod或容器使用过多的资源而导致其他应用无法运行。同样，在Kubernetes中，资源限制通常也包括CPU和内存等资源。
在Kubernetes中，还可以通过一些高级特性进行更细致的资源管理，例如使用LimitRange对象定义Pod或容器的默认资源请求和限制，或者自定义资源类型等。

5.1 示例

在Kubernetes中，可以通过以下方式限制资源：
- 限制CPU使用率。通过设置Pod或容器的CPU使用率上限，可以避免某些应用程序占用过多的CPU资源导致其他应用程序无法正常运行。
  - 例如，使用以下命令来为Pod设置CPU使用率上限为2核心：
    apiVersion: v1 kind: Pod metadata: name: cpu-demo namespace: cpu-example spec: containers: - name: cpu-demo-ctr image: v1.0 resources: limits: cpu: "2" requests: cpu: "1"
- 调整内存分配。根据应用程序的需求和系统可用内存情况，调整内存分配比例，以确保每个应用程序都能得到足够的内存空间。
  - 例如，使用以下命令来为Pod设置内存分配为4Gi：
    apiVersion: v1 kind: Pod metadata: name: mem-demo namespace: mem-example spec: containers: - name: mem-demo-ctr image: v1.0 resources: limits: memory: "4Gi" requests: memory: "2Gi"
5.2 超过限制会出现什么情况？

在 Kubernetes 集群中，可以通过设置资源限制来控制容器可以使用的计算资源，例如 CPU 和内存。如果容器使用的资源超过了这些限制，将会出现以下情况：
1. Pod 被 Kubernetes 控制器（如 ReplicationController、Deployment 等）杀死：如果 Pod 的资源使用超过了指定的限制，Kubernetes 控制器可能会认为该 Pod 无法正常工作，并将其杀死以保护集群资源。
2. Pod 被 Kubernetes API 服务器杀死：Kubernetes API 服务器可以检测到 Pod 的资源使用情况，如果超过了限制，API 服务器可以将该 Pod 标记为异常状态，并最终杀死它。
3. 节点 OOM（Out of Memory）：如果容器使用的内存超过了节点的可用内存，节点可能会出现 OOM 异常，导致容器崩溃或无法正常工作。
因此，在使用 Kubernetes 集群时，需要合理设置容器的资源限制，以避免出现上述问题。如果需要容器使用更多的资源，可以考虑增加集群资源或者对 Pod 进行特殊配置。

6、自动扩展和收缩

Kubernetes 提供了多种方法来实现自动扩展和收缩。以下是其中两种常见的方法：
1. Horizontal Pod Autoscaler（HPA）：HPA 是 Kubernetes 内置的自动扩展控制器，它可以根据 Pod 的 CPU 或内存使用情况自动调整 Pod 的副本数量。HPA 通过监听 Pod 的监控指标（如 CPU 利用率、内存使用率等）来判断是否需要扩展或收缩 Pod 的副本数量。当 Pod 的资源使用达到指定的阈值时，HPA 会自动创建新的 Pod 副本，以满足更高的请求。同样，当 Pod 的资源使用下降时，HPA 也会自动删除多余的 Pod 副本，以节省资源。
2. Kubernetes Deployment：Deployment 是 Kubernetes 中的一种资源对象，用于管理应用的部署和扩展。通过设置 Deployment 的 replicaCount 属性，可以指定应用的副本数量。Kubernetes 会自动管理 Deployment 的副本数量，根据 Pod 的状态和资源使用情况进行扩展和收缩。
除了上述两种方法，还可以使用 Kubernetes 自定义控制器或第三方扩展工具来实现自动扩展和收缩。无论采用哪种方法，都需要根据应用的需求和资源使用情况来合理设置扩展和收缩策略，以确保集群的稳定和高效运行。

6.1 Horizontal Pod Autoscaler-示例

Horizontal Pod Autoscaler（HPA）是 Kubernetes 中的一个自动伸缩控制器，用于根据 CPU 或内存等资源使用情况自动调整 Pod 的副本数量。

以下是一个简单的 HPA 示例：
```
apiVersion: autoscaling/v2beta2
kind: HorizontalPodAutoscaler
metadata:
  name: my-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
```
        在这个示例中，我们定义了一个名为 “my-hpa” 的 HPA，它关联到一个名为 “my-deployment” 的 Deployment。HPA 将根据 “my-deployment” 中 Pod 的 CPU 利用率，自动调整副本数量，最小副本数为 1，最大副本数为 10。当 CPU 利用率达到 50% 时，HPA 将自动增加副本数量，直到达到最大副本数；反之，当 CPU 利用率下降时，HPA 将自动减少副本数量，直到达到最小副本数。

        需要注意的是，HPA 需要与 Kubernetes API Server 和 Kubernetes Controller Manager 配合使用，才能实现自动伸缩功能。您需要在 Kubernetes 集群中正确配置和启动这些组件。

6.2 Kubernetes Deployment-示例

        在 Kubernetes 中，自动扩展可以通过 Kubernetes API 服务器进行配置。以下是一个简单的示例，展示了如何使用 Kubernetes API 服务器配置自动扩展：
1. 创建一个 Kubernetes Deployment 资源对象，其中包含您要部署的应用程序的详细信息，例如镜像、容器运行时、端口等。
```
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        name: my-app
        image: my-image:v1
        ports:
          - containerPort: 8080
```
        在上面的示例中，scaleTargetRef字段指定了要进行自动扩展的 Deployment 资源对象的名称和 API 版本。minReplicas和maxReplicas字段分别指定了最小副本数和最大副本数。metrics字段指定了要使用的扩展指标，在这个示例中，我们使用了 CPU 使用率作为扩展指标。

        当 CPU 使用率达到 80%时，Kubernetes 会自动扩展 Deployment 中的副本数量，将副本数量增加到最大副本数（在这个示例中为 10）。当 CPU 使用率下降到低于 80%时，Kubernetes 会自动减少副本数量，将副本数量减少到最小副本数（在这个示例中为 1）。

6.3 Horizontal Pod Autoscaler和Kubernetes Deployment比较

        Horizontal Pod Autoscaler 和 Kubernetes Deployment 都是 Kubernetes 中用于自动扩展的重要资源对象，但它们的使用场景和复杂程度略有不同。

        Kubernetes Deployment 是一种更通用的资源对象，它可以用于部署和管理应用程序的多个实例。通过 Kubernetes Deployment，您可以定义应用程序的副本数量、容器配置、滚动更新等信息，从而实现应用程序的自动化部署和扩展。

        Horizontal Pod Autoscaler 则是专门用于自动扩展 Pod 副本数量的资源对象。它通过监控 Pod 的资源使用情况（如 CPU 利用率）来动态调整 Pod 的副本数量，以满足业务需求。Horizontal Pod Autoscaler 通常与 Kubernetes Deployment 配合使用，以实现 Pod 副本数量的自动扩展。

        因此，哪种方式更简单取决于您的具体需求和使用场景。如果您需要更灵活的扩展策略，或者需要对应用程序进行更复杂的管理，那么 Kubernetes Deployment 可能更适合您。如果您只需要简单地自动扩展 Pod 副本数量，那么 Horizontal Pod Autoscaler 可能更简单。

        无论您选择哪种方式，都需要对 Kubernetes 集群进行充分的测试和调优，以确保其能够满足您的业务需求。

6.4 适用场景
- 访问量增长：资源消耗缓慢增加。比如产品日活人数增加后，访问量也会增加。
- 微服务：根据微服务的负载情况自动调整每个服务实例的资源分配。
- 多租户：自动伸缩可以为不同的租户或工作负载提供独立的伸缩策略，以确保每个租户或工作负载都能获得所需的资源。
7、Kubernetes和spring cloud

7.1 重叠功能
1. 服务发现和注册：Kubernetes的Service资源可以帮助微服务应用程序实现服务发现和注册，而Spring Cloud的Eureka也提供了类似的功能。
2. 负载均衡：Kubernetes的Service资源提供了负载均衡功能，而Spring Cloud的Ribbon和Eureka也提供了负载均衡功能，它们可以相互补充，但功能类似。
3. 配置管理：Kubernetes 和 Spring Cloud 都提供了配置管理的功能，可以帮助您管理和部署应用程序的配置。
4. 监控和日志：Kubernetes 和 Spring Cloud 都提供了监控和日志的功能，可以帮助您监控和分析应用程序的运行情况。
7.2 相互补充
- 自动扩展：Kubernetes 提供了自动扩展的功能，可以根据负载情况自动增加或减少服务实例的数量。Spring Cloud没有这个功能。
- 网关：Spring Cloud的spring cloud Gateway提供了网关功能，Kubernetes网关是Ingress。
  - 作用。Kubernetes网关是Ingress或Gateway API，主要作用是路由和负载均衡；Spring Cloud Gateway是一个API网关，主要作用是安全、限流、路由和监控。
  - 使用场景 。Kubernetes网关通常用在云平台中，作为集群的入口；Spring Cloud Gateway通常用在Spring Cloud微服务架构中，作为微服务的入口。
  - 集成。Kubernetes网关可以和Spring Cloud集成，但通常需要额外配置；Spring Cloud Gateway已经和Spring Cloud集成，可以方便地使用Spring Cloud提供的各种功能。
- 断路器：Spring Cloud的Hystrix提供了断路器功能，而Kubernetes没有这个功能，因此需要与Spring Cloud配合使用。
Kubernetes Ingress配置的示例
1. 创建一个Ingress对象，定义规则和后端服务。
```
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    # 定义负载均衡器的类型为 roundrobin
    # 使用这个注解可以设置负载均衡策略
    # 可选的负载均衡策略有 'RoundRobin', 'LeastRequests', 'WeightedRoundRobin', 'WeightedLeastRequests' 等
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "my-affinity-cookie"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        backend:
          serviceName: my-service
          servicePort: 80
```
2. 创建一个Ingress Controller，可以选择已有的Ingress Controller，如Nginx Ingress Controller，或者自定义一个。
3. 确认Ingress Controller已经正确地部署在集群中，并且Ingress Controller的POD已经正常地运行。
4. 确认Ingress Controller已经成功地与Ingress对象进行了通信，并且已经正确地处理了流量路由规则。
8、其他

其他功能暂时先不写了。

参考文章：

【K8S系列】深入解析滚动升级_k8s滚动更新_颜淡慕潇的博客-CSDN博客
相关阅读:
创新案例｜巴黎欧莱雅如何以内容+货架双轮驱动全渠道兴趣电商增长飞轮
 基于cobra的go语言命令行解析器
 vulnhub靶场之CONTAINME: 1
项目九、无线组网
 无涯教程-Flutter - 简介
 字节跳动面试官：请你实现一个大文件上传和断点续传
 Android项目---拼图小游戏（下）
http协议与https协议+UDP协议和TCP协议+WebSocket协议下服务端主动去发送信息+对称加密与非对称加密+get和post请求方式区别详解
 【大家的项目】通用规则引擎——Rush（一）可以自定义的规则引擎，告别发版，快速配置...
电脑怎么把照片变成jpg格式?
原文地址：https://blog.csdn.net/xixingzhe2/article/details/132835776

1、功能

1.1 主要功能

1.2 概念映射-个人观点

pod、service和spring cloud类比

Kubernetes与spring cloud区别

2、容器编排

2.1 ReplicaSet对象

2.2 pod

2.2.1 问题-Kubernetes如何判断应用程序存活的？

2.2.2 Pod状态

2.2.3 Pod的重启策略

2.2.4 Kubernetes的探针类型

2.2.4.1 Kubernetes的探针使用方法

2.2.4.2 httpGet-示例

3、服务发现和负载均衡

4、自动部署和回滚

滚动更新

更新过程

示例

Kubernetes滚动更新问题

要停止的pod正在处理程序，如何处理？

新版pod替换旧版pod，是两个版本同时存在，都是启动状态吗？

新版pod替换旧版pod，新版pod是不是还不可用，要有一个启动过程？

Kubernetes滚动更新过程，新旧两版接口会同时存在吗？

新版接口刚升级一个节点提供服务，是否有服务器被压垮的风险？

微服务升级

举例

5、资源管理

5.1 示例

5.2 超过限制会出现什么情况？

6、自动扩展和收缩

6.1 Horizontal Pod Autoscaler-示例

6.2 Kubernetes Deployment-示例

6.3 Horizontal Pod Autoscaler和Kubernetes Deployment比较

6.4 适用场景

7、Kubernetes和spring cloud

7.1 重叠功能

7.2 相互补充

Kubernetes Ingress配置的示例

8、其他