K8s 相关问题集锦（二）
5. 高可用与扩展类
5.1 HPA（Horizontal Pod Autoscaler)
Horizontal Pod Autoscaler (HPA) 是 Kubernetes 中的一个自动扩展机制，用于根据某些指标（通常是 CPU、内存使用率或其他自定义指标）来自动调整 Pod 的副本数，以确保应用程序能够在负载变化时维持良好的性能。它通过监控指标数据，并根据预设的目标值调整 Deployment 或 ReplicaSet 中 Pod 的数量。
Horizontal Pod Autoscaler (HPA) 是 Kubernetes 中用来管理 Pod 副本数量的自动扩展机制 。它关注的是如何根据负载（例如 CPU 使用率或自定义指标）来动态调整某个特定应用（如 Deployment、ReplicaSet）中的 Pod 数量。因此，它可以被看作是 在应用层面进行的 Pod 副本的集群管理 ，目的是确保某个服务在负载增加时有足够的 Pod 处理请求，在负载降低时又能自动缩减 Pod 数量以节省资源。
HPA 工作原理
- HPA 定期查询指标（如 CPU 使用率）并计算所需的副本数量。
- 如果当前的资源使用率高于设定的目标值，HPA 会增加 Pod 的副本数；如果使用率低于目标值，则会减少副本数。
- HPA 的配置通常基于 Kubernetes Metrics Server 来获取指标数据。部署 Metrics Server 是配置 HPA 的前提条件。
HPA 配置示例
以下是配置 HPA 的具体步骤和命令示例：
前提条件
确保 Kubernetes 集群中已经安装并运行 Metrics Server，可以使用以下命令查看 Metrics Server 是否正常工作：
bash kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"如果返回的节点数据包含 CPU 和内存使用情况，说明 Metrics Server 正常工作。
1. 创建 Deployment
假设我们创建一个名为
nginx-deployment的 Deployment，运行一个 nginx 容器：
bash kubectl create deployment nginx-deployment --image=nginx --replicas=2这将会创建一个有 2 个副本的 Deployment，镜像为
nginx。2. 配置 HPA
使用
kubectl autoscale命令为nginx-deployment创建一个 HPA：
bash kubectl autoscale deployment nginx-deployment --cpu-percent=50 --min=2 --max=10
--cpu-percent=50：目标 CPU 使用率为 50%。当 Pod 的平均 CPU 使用率高于 50% 时，HPA 会增加副本数；当低于 50% 时，HPA 会减少副本数。--min=2：最小副本数为 2，保证至少有 2 个 Pod 在运行。--max=10：最大副本数为 10，保证即使负载增加，副本数也不会超过 10。3. 验证 HPA
使用以下命令查看 HPA 的状态：
bash kubectl get hpa你会看到类似如下的输出：
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE nginx-deployment Deployment/nginx-deployment 40%/50% 2 10 3 5m
TARGETS：显示当前 CPU 使用率和目标值（如 40%/50%）。MINPODS和MAXPODS：显示配置的最小和最大 Pod 副本数。REPLICAS：当前实际运行的副本数。4. 修改 HPA
可以使用
kubectl edit命令来修改 HPA 的配置。例如，调整 CPU 使用率目标或最大最小副本数：
bash kubectl edit hpa nginx-deployment或者直接使用 YAML 文件修改配置。
5. 使用 YAML 文件配置 HPA
你也可以使用 YAML 文件配置 HPA，创建一个名为
hpa.yaml的文件，内容如下：
yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: nginx-deployment-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: nginx-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 50应用该配置：
bash kubectl apply -f hpa.yaml6. 测试 HPA
可以通过增加负载来测试 HPA 的效果。例如，运行一个负载生成器来增加 nginx 的 CPU 使用率：
bash kubectl run -i --tty load-generator --image=busybox /bin/sh在
busybox容器中，运行以下命令来向 nginx 发送持续请求，增加 CPU 负载：
bash while true; do wget -q -O- http://nginx-deployment; done在负载增加后，HPA 会自动增加
nginx-deployment的 Pod 副本数，以应对增加的请求量。可以使用kubectl get hpa观察 Pod 数量的变化。7. 删除 HPA
如果不再需要 HPA，可以使用以下命令删除：
bash kubectl delete hpa nginx-deployment小结
- HPA 能够根据应用程序的负载情况，自动调整 Pod 的副本数量，以提高资源利用率和系统的稳定性。
- 在实际应用中，配置 HPA 时需要综合考虑应用的特点、集群容量、响应时间等因素。
- HPA 的应用场景包括 Web 服务、API 服务等需要根据负载波动进行自动扩展的场景。
5.2 集群的高可用性
讨论对 Master 节点的高可用性（如多 Master 节点部署）和 etcd 集群的高可用性，以及对负载均衡器的使用。
配置多 Master 节点的高可用需要的额外组件和配置
- 配置负载均衡器（如 HAProxy）以均衡 API Server 的请求。
- 配置
etcd集群进行数据冗余，所有kube-apiserver实例连接到同一个etcd集群。 - 确保正确配置 TLS 证书，尤其是在多个 API Server 实例和负载均衡器之间的通信。
- 配置和管理 Master 节点之间的时间同步。
- 使用
kube-scheduler和kube-controller-manager的 Leader Election 确保单一活跃实例。 - 定期备份
etcd数据，并制定灾难恢复策略。
5.2.1 多个Master节点与 etcd集群的关系：
Kubernetes 中 Master 节点的高可用性与 etcd 集群的高可用性 并不是完全独立的过程，而是紧密关联的，需要同时配置。
原因解析：
etcd 是 Kubernetes 控制平面的数据存储核心：
etcd存储了 Kubernetes 的所有配置、状态和集群的元数据，比如所有的 Pod、Service、ConfigMap 等信息。所有对 Kubernetes API 的变更（如创建、更新、删除资源）都会记录在etcd中。- Kubernetes 控制平面（即
kube-apiserver、kube-scheduler、kube-controller-manager）需要与etcd通信来获取集群状态和写入状态变更。多 Master 节点需要连接到同一个 etcd 集群：
当配置多 Master 节点时，所有的
kube-apiserver实例都需要连接到同一个etcd集群，以保持一致的数据视图。- 如果
etcd集群不可用，那么即使有多个 Master 节点，这些kube-apiserver也会因为无法访问etcd数据而变得无效。etcd 的高可用性决定了数据的可用性和一致性：
在高可用的 Kubernetes 集群中，
etcd通常会部署为 3 个或更多节点的集群，以确保在某些etcd节点失效时，其他节点可以继续工作。- 如果
etcd没有配置高可用性，即使 Master 节点是多副本部署的，也无法保证集群的稳定性和数据的一致性。因此，高可用配置需要同时考虑以下两个方面：
etcd 集群的高可用性：
使用至少 3 个节点的
etcd集群，保证数据的持久性和容错能力。- 配置
etcd节点互相通信和同步数据，确保在发生单节点故障时集群依然可以选举出新的leader并继续运行。Master 节点的高可用性：
多个 Master 节点上运行
kube-apiserver、kube-scheduler和kube-controller-manager，通过负载均衡器均衡对kube-apiserver的请求。- 所有
kube-apiserver实例都需要连接到同一个高可用的etcd集群，以保证一致的数据视图。高可用配置的关系示例：
假设我们有 3 台服务器，分别为
master1、master2和master3：
- 在每个 Master 节点上 部署一个
etcd节点，同时部署一个kube-apiserver、kube-scheduler和kube-controller-manager。- 配置
kube-apiserver使用etcd集群的多个地址，例如：bash kube-apiserver --etcd-servers=http://master1:2379,http://master2:2379,http://master3:2379- 使用一个负载均衡器（如 HAProxy）将外部的 API 请求均衡分发到多个
kube-apiserver实例。这种配置方式确保：
- 即使
master1故障，其他两个etcd节点和kube-apiserver实例依然可以正常工作，保证集群的可用性。- 当
etcd中的某个节点出现问题时，剩余的etcd节点可以继续提供数据服务，避免kube-apiserver无法获取集群状态。总结
- Master 节点的高可用性与
etcd高可用性是紧密关联的，两者需要同时配置。etcd的高可用性保证了数据存储的可靠性和一致性，而多 Master 节点保证了集群控制平面的冗余和负载均衡。- 如果只配置 Master 节点的高可用性而不配置
etcd的高可用性，etcd一旦出问题，整个集群仍然会不可用。因此，在设计 Kubernetes 集群的高可用性时，需要从整体出发，确保控制平面和数据存储都具备足够的冗余和容错能力。
5.2.2 Master节点与 etcd集群 的具体配置过程：
Kubernetes 控制平面负责集群的管理和调度，主要组件包括
kube-apiserver、kube-controller-manager、kube-scheduler和etcd。为了实现控制平面的高可用性，通常需要配置多个 Master 节点。多 Master 节点部署
- 目的：多个 Master 节点可以提供冗余，避免单个 Master 节点失效导致整个集群不可用。
- 配置：
- 在生产环境中，建议至少部署 3 个 Master 节点。这样可以保证当其中一个节点失效时，集群依然可以继续工作。
kube-apiserver是无状态的，可以在多个 Master 节点上同时运行。kube-scheduler和kube-controller-manager需要以leader election模式运行，确保只有一个实例在活动状态，而其他实例处于备用状态。在 Kubernetes 中，实现控制平面（Master 节点）的高可用性，涉及部署多个 Master 节点，并配置负载均衡器来均衡对
kube-apiserver的请求，确保即使部分 Master 节点故障，整个集群依然能够正常工作。以下是具体的配置步骤，包括 Master 节点的设置、etcd 集群的配置以及负载均衡器的配置。前提条件
- 至少 3 台服务器（推荐 3 台以上的奇数台服务器，以确保 etcd 集群在发生故障时仍能选举 leader）。
- 每台服务器都需要有以下组件：
- Kubernetes 控制平面组件（
kube-apiserver、kube-controller-manager、kube-scheduler）。- etcd（用于存储 Kubernetes 的状态数据）。
- 一个负载均衡器（可以是硬件设备，也可以是基于软件的 HAProxy、Nginx 等）。
1. 部署多 Master 节点
步骤 1：安装
kube-apiserver、kube-controller-manager和kube-scheduler在每个 Master 节点上，安装并配置以下组件：
- kube-apiserver: 它是无状态的，可以在每个 Master 节点上运行实例。
- kube-scheduler 和 kube-controller-manager: 需要配置为启用
leader election，确保只有一个实例在活动状态。例如，在
kube-controller-manager配置中启用leader election:
bash kube-controller-manager --leader-elect=true步骤 2：配置
etcd集群在每个 Master 节点上，安装
etcd，并配置它们互相通信。假设我们有 3 个 Master 节点：
master1(IP: 192.168.1.1)master2(IP: 192.168.1.2)master3(IP: 192.168.1.3)在每个节点上，启动
etcd并配置集群信息：
master1上的配置示例：
bash etcd --name etcd1 \ --initial-advertise-peer-urls http://192.168.1.1:2380 \ --listen-peer-urls http://0.0.0.0:2380 \ --advertise-client-urls http://192.168.1.1:2379 \ --listen-client-urls http://0.0.0.0:2379 \ --initial-cluster etcd1=http://192.168.1.1:2380,etcd2=http://192.168.1.2:2380,etcd3=http://192.168.1.3:2380 \ --initial-cluster-state new
master2和master3上的配置类似，只需替换--name和--initial-advertise-peer-urls的值。步骤 3：配置
kube-apiserver使用etcd集群在每个 Master 节点上，启动
kube-apiserver并配置--etcd-servers连接到 etcd 集群的所有节点：
bash kube-apiserver --etcd-servers=http://192.168.1.1:2379,http://192.168.1.2:2379,http://192.168.1.3:2379 \ --other-flags...这样，
kube-apiserver就可以连接到多个etcd节点，保证即使部分 etcd 节点失效，集群数据依然可以访问。
5.2.3 负载均衡器（Load Balancer）
为什么负载均衡器是必要的？
分发流量 ：
在 Kubernetes 中，多 Master 节点意味着有多个
kube-apiserver实例在运行。负载均衡器的主要作用是 将来自客户端（如kubectl）或其他集群组件（如kubelet、kube-proxy）的请求，均衡地分发到这些kube-apiserver实例上 。这不仅优化了流量分布，还确保了即使某个
kube-apiserver实例出现故障，其他的实例依然可以继续处理请求。提高集群的可用性 ：
如果没有负载均衡器，客户端和内部组件就需要直接与某个固定的
kube-apiserver进行交互。一旦这个kube-apiserver所在的 Master 节点失效，客户端就无法与集群进行通信， 集群的高可用性将会失去意义 。通过负载均衡器，即使某个
kube-apiserver节点不可用，负载均衡器可以自动将请求路由到其他可用的 Master 节点，从而实现对kube-apiserver的高可用性。简化 API Server 的访问 ：
使用负载均衡器，可以为所有
kube-apiserver实例提供一个统一的访问地址。无论有多少个 Master 节点，客户端都只需要知道负载均衡器的地址即可。这大大简化了集群的管理和维护。负载均衡器的部署方式
- 云平台的负载均衡服务 ：对于在云平台（如 AWS、GCP、Azure）上部署的 Kubernetes 集群，可以直接使用这些平台提供的负载均衡服务（如 AWS 的 ELB、GCP 的 Load Balancer 等）。
- 自建软件负载均衡器 ：在裸机环境或自建的数据中心，可以使用开源的负载均衡软件，如 HAProxy 、Nginx 或 Keepalived ，将外部请求转发给不同的 Master 节点的
kube-apiserver。在配置 Kubernetes 多 Master 节点的高可用性时，除了搭配
etcd集群外，还需要配置以下几个重要的组件和机制，以确保整个集群的高可用性和稳定性：1. 负载均衡器（Load Balancer）
负载均衡器 是多 Master 节点高可用配置中的关键部分，用于将对
kube-apiserver的请求均衡地分发到多个 Master 节点。这样即使某个 Master 节点失效，请求也可以自动转发到其他可用的 Master 节点。负载均衡器的配置选项：
- 云平台的负载均衡器：如果 Kubernetes 集群部署在云环境中（如 AWS、GCP、Azure 等），可以使用云提供的负载均衡服务（如 AWS ELB 或 GCP Load Balancer）。
- 自建负载均衡器：在裸机或虚拟机环境中，可以使用软件负载均衡器，如 HAProxy、Nginx、Keepalived 等。
HAProxy 配置示例：
/etc/haproxy/haproxy.cfg：```haproxy frontend kubernetes-api bind *:6443 mode tcp default_backend kubernetes-api-backend
backend kubernetes-api-backend mode tcp balance roundrobin server master1 192.168.1.1:6443 check server master2 192.168.1.2:6443 check server master3 192.168.1.3:6443 check ```
- 这将
kubectl或集群内部组件发往https://<haproxy-ip>:6443的请求均衡地分发到kube-apiserver实例。4. 数据备份和恢复
负载均衡链接的IP地址
在配置 Kubernetes 控制平面的高可用性时，外部负载均衡器的链接 IP 通常指的是 各个 Master 节点上
kube-apiserver的 IP 地址和端口。这个端口是kube-apiserver监听的端口，通常是 6443。它既不是NodePort，也不是ClusterIP，而是直接连接到每个 Master 节点上kube-apiserver所绑定的地址。详细解释
在多 Master 节点高可用配置中，
kube-apiserver在每个 Master 节点上直接监听一个固定的 IP 地址和端口，通常是https://<master-ip>:6443，这是 Kubernetes 集群的控制平面通信所使用的地址。外部负载均衡器会将流量直接转发到这些kube-apiserver实例。负载均衡器连接的 IP 配置示例
假设我们有 3 个 Master 节点，IP 地址如下：
master1：192.168.1.1master2：192.168.1.2master3：192.168.1.3每个 Master 节点的
kube-apiserver都监听在各自节点的 6443 端口，因此负载均衡器的后端配置应该是连接到这些地址的 6443 端口。使用 HAProxy 配置负载均衡器的示例
在负载均衡器（例如 HAProxy）上，配置文件
/etc/haproxy/haproxy.cfg可能如下：```haproxy frontend kubernetes-api bind *:6443 mode tcp default_backend kubernetes-api-backend
backend kubernetes-api-backend mode tcp balance roundrobin server master1 192.168.1.1:6443 check server master2 192.168.1.2:6443 check server master3 192.168.1.3:6443 check ```
- frontend 部分：监听负载均衡器的外部 IP 地址的
6443端口，将请求转发到backend。- backend 部分：定义后端的
kube-apiserver实例。server配置中指向了kube-apiserver在每个 Master 节点上的 IP 地址和端口6443。总结
- 外部负载均衡器的后端连接指向的是每个 Master 节点的
kube-apiserver地址和端口，即https://<master-ip>:6443。- 这里的
6443是kube-apiserver的默认监听端口，用于处理来自kubectl、kubelet和其他 Kubernetes 组件的 API 请求。- NodePort 和 ClusterIP 主要用于集群内部服务的通信和暴露，而不是用于
kube-apiserver的外部负载均衡。通过这种配置，当
kubectl或集群中的其他组件向负载均衡器发送请求时，负载均衡器会将请求转发到可用的kube-apiserver实例，从而实现对控制平面的高可用访问。希望这能帮助你理解外部负载均衡器的配置方式，如果有其他问题，随时问我！
附件： 负载均衡高可用
负载均衡器本身也是一个软件或设备，如果希望负载均衡器也具备高可用性，那么通常需要配置多个负载均衡器实例，并对这些实例进行冗余部署。这样，即使某个负载均衡器节点出现故障，另一个负载均衡器节点仍然可以继续工作，从而确保整个集群的高可用性。
高可用负载均衡器的配置方式
高可用负载均衡器的配置方式通常包括以下两种：
使用 Keepalived 实现虚拟 IP（VIP）高可用性：
在裸机或自建数据中心环境中，可以使用 Keepalived 配置一个虚拟 IP 地址（VIP），这个 VIP 会漂移到活动状态的负载均衡器实例上。
- 当一个负载均衡器节点（如 HAProxy 或 Nginx）失效时，VIP 会自动切换到另一个健康的负载均衡器节点上，客户端始终使用同一个 VIP 进行访问。
- 这种方式可以实现负载均衡器的冗余，并在节点故障时自动进行故障切换。
#### Keepalived 配置示例
假设我们有两台服务器
lb1和lb2，它们都运行 HAProxy，并使用 Keepalived 来管理 VIP：lb1（192.168.1.1）的 Keepalived 配置：
keepalived vrrp_instance VI_1 { state MASTER interface eth0 virtual_router_id 51 priority 100 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.1.100 } }lb2（192.168.1.2）的 Keepalived 配置：
keepalived vrrp_instance VI_1 { state BACKUP interface eth0 virtual_router_id 51 priority 90 advert_int 1 authentication { auth_type PASS auth_pass 1234 } virtual_ipaddress { 192.168.1.100 } }
state：在lb1上配置为MASTER，表示它默认是主节点；在lb2上配置为BACKUP，表示它是备份节点。priority：lb1的优先级高于lb2，因此当lb1正常运行时，VIP 会绑定到lb1。如果lb1故障，VIP 会自动切换到lb2。virtual_ipaddress：虚拟 IP 地址192.168.1.100，客户端使用这个 IP 来访问负载均衡器。这样，客户端始终使用
192.168.1.100作为访问入口，即使lb1失效，Keepalived 会自动将 VIP 切换到lb2，从而实现高可用。 2. 使用云平台的负载均衡服务：
- 如果你的 Kubernetes 集群部署在云环境（如 AWS、GCP、Azure），可以使用云提供的负载均衡服务。云平台通常会自动为你管理负载均衡器的高可用性。
- 例如，在 AWS 中，你可以使用 Elastic Load Balancer (ELB)，它会自动分布在多个可用区（Availability Zones）内，即使某个负载均衡器实例出现问题，AWS 也会自动提供冗余。
- 这种方式非常适合云上部署的集群，因为无需自己管理负载均衡器的高可用性，只需配置好负载均衡器的目标组，将 Master 节点添加为后端。
为什么需要多个负载均衡器节点？
配置多个负载均衡器节点的好处在于：
- 避免单点故障：如果只有一个负载均衡器实例，那么一旦该实例故障，集群的 API Server 就不可访问，整个 Kubernetes 控制平面的高可用性也就失去了意义。
- 更好的服务稳定性：多个负载均衡器节点能够更好地处理高流量请求，避免单个实例成为性能瓶颈。
- 实现无缝故障切换：通过 Keepalived 或云平台的高可用机制，可以在负载均衡器实例故障时无缝切换到备份节点，提升集群的可靠性。
- 负载均衡器在 Kubernetes 高可用配置中是必须的，但如果希望负载均衡器本身具备高可用性，需要部署多个负载均衡器实例。
- 可以通过 Keepalived 配置虚拟 IP 实现负载均衡器的高可用性，或者使用 云平台提供的负载均衡服务，从而保证即使某个负载均衡器节点失效，集群依然可以正常工作。
- 核心思路 是消除负载均衡器的单点故障，确保整个 Kubernetes 集群在面对各种硬件或网络问题时能够持续提供服务。
5.2.4 服务发现和 DNS 配置
在高可用环境中，需要确保 所有 Master 节点的 API Server 能够被集群内部组件正确地访问。除了负载均衡器，还需要配置服务发现机制，使得组件能够在不同 Master 节点间自动切换。
- CoreDNS：Kubernetes 默认使用 CoreDNS 来管理集群内部的 DNS 解析，确保
kubelet和其他组件可以正确解析服务和节点的地址。- External DNS：如果需要从集群外部访问 API Server，也可以配置 DNS 服务以指向负载均衡器的 IP。
在高可用的 Kubernetes 集群中，配置 CoreDNS 和 External DNS 可以确保集群内部和外部的组件能够正确地访问
kube-apiserver和其他服务。以下是关于这两者的配置方法：1. 配置 CoreDNS
Kubernetes 集群默认使用 CoreDNS 作为 DNS 服务器，用于解析集群内部的服务名称。CoreDNS 负责将服务名称解析为
ClusterIP，使得集群内部的 Pod 和服务能够通过 DNS 名称进行通信。CoreDNS 的配置方法
CoreDNS 通常在
kubeadm初始化集群时自动安装，并作为kube-system命名空间中的一个Deployment运行。它的配置文件通常存储在ConfigMap中：
- 查看 CoreDNS 的
ConfigMap：
bash kubectl -n kube-system get configmap coredns -o yaml- 典型的CoreDNS配置文件（ConfigMap中）：
yaml apiVersion: v1 kind: ConfigMap metadata: name: coredns namespace: kube-system data: Corefile: | .:53 { errors health { lameduck 5s } ready kubernetes cluster.local in-addr.arpa ip6.arpa { pods insecure fallthrough in-addr.arpa ip6.arpa ttl 30 } prometheus :9153 forward . /etc/resolv.conf cache 30 loop reload loadbalance }- 配置说明：
kubernetes段配置了用于解析 Kubernetes 服务的cluster.local域。forward段定义了如何将未匹配的请求转发到集群外部的 DNS 服务器。cache段用于缓存解析结果，减少 DNS 请求的延迟。CoreDNS 的常见操作
- 重启 CoreDNS：如果修改了 CoreDNS 的配置，需要重启
corednsPod 使配置生效：bash kubectl -n kube-system rollout restart deployment coredns2. 配置 External DNS
External DNS 是为了确保从集群外部访问 API Server 时能够解析到负载均衡器的 IP 地址。这种配置通常用于以下场景：
- 在自建的数据中心环境中，你有一个 内部或外部 DNS 服务器，希望能够通过域名访问 Kubernetes 的
kube-apiserver。- 在云环境中，使用 云提供的 DNS 服务（如 AWS Route 53、GCP Cloud DNS）来解析 API Server 的域名。
使用外部 DNS 解析负载均衡器的 IP
假设负载均衡器的 IP 是
203.0.113.10，我们希望通过api.k8s.example.com来访问 Kubernetes API Server。可以在外部 DNS 服务器中添加以下记录：
- A 记录：
api.k8s.example.com. IN A 203.0.113.10
- 类型：A 记录
- 名称：api.k8s.example.com
- 值：203.0.113.10（负载均衡器的 IP）
这种方式确保所有访问
api.k8s.example.com的请求都被解析到负载均衡器的 IP。在云环境中配置 External DNS（以 AWS 为例）
在云平台中，你可以使用 ExternalDNS 工具来自动管理域名解析。ExternalDNS 是一个开源项目，可以根据 Kubernetes 的服务自动创建和管理 DNS 记录。以下是使用 ExternalDNS 的示例步骤（以 AWS Route 53 为例）：
- 安装 ExternalDNS： 创建一个
external-dns.yaml文件并部署：
yaml apiVersion: apps/v1 kind: Deployment metadata: name: external-dns namespace: kube-system spec: replicas: 1 selector: matchLabels: app: external-dns template: metadata: labels: app: external-dns spec: containers: - name: external-dns image: bitnami/external-dns:latest args: - --source=service - --source=ingress - --domain-filter=example.com - --provider=aws - --policy=sync - --aws-zone-type=public- 配置说明：
--source=service和--source=ingress：ExternalDNS 会根据 Kubernetes 中的服务和 Ingress 创建 DNS 记录。--domain-filter=example.com：只处理example.com域的 DNS 记录。--provider=aws：使用 AWS 作为 DNS 服务提供商。--policy=sync：同步 Kubernetes 资源与 DNS 记录。- 部署 ExternalDNS：
bash kubectl apply -f external-dns.yaml- AWS IAM 权限配置： 确保 ExternalDNS 运行的服务账户具有操作 Route 53 的权限，例如，可以为 ExternalDNS 配置以下 IAM 权限：
json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "route53:ChangeResourceRecordSets", "route53:ListHostedZones", "route53:ListResourceRecordSets" ], "Resource": ["*"] } ] }总结
CoreDNS 配置：
负责集群内部的服务发现和 DNS 解析，确保
kubelet、Pod和其他 Kubernetes 组件能正确解析服务的 DNS 名称。- 通常在集群初始化时自动配置，可以通过修改
ConfigMap来调整。External DNS 配置：
用于确保从外部能够访问到 Kubernetes API Server 或其他暴露在外部的服务。
- 可以在自建 DNS 服务器中手动添加 A 记录，也可以使用工具（如 ExternalDNS）在云平台上自动管理域名解析。
- 负载均衡器的 IP 是外部 DNS 指向的目标，通常是
api.<domain>指向负载均衡器的 IP，从而将外部访问请求转发到负载均衡器，再由负载均衡器分发到各个kube-apiserver。通过这种方式，你可以确保 Kubernetes 集群内部和外部的 DNS 配置都能支持高可用的访问。希望这些信息对你有帮助，如果还有其他问题或需要更详细的解释，欢迎继续交流！
5.2.5 集群证书管理
由于
kube-apiserver和其他组件之间的通信通常通过 HTTPS 进行，因此在高可用环境下，必须正确配置 TLS 证书。特别是多 Master 节点时，确保证书在所有 Master 节点上是相同的。
- CA（Certificate Authority）证书：所有
kube-apiserver实例和etcd节点需要信任同一个 CA。- API Server 证书：如果使用负载均衡器，可以为负载均衡器配置一个通配符证书，或者使用所有 Master 节点的主机名作为 SAN（Subject Alternative Name）。
- 自动化证书管理：可以使用工具（如
kubeadm或cert-manager）简化证书的创建和管理。这些 TLS 证书主要用于 Kubernetes 内部组件之间的通信，特别是与
kube-apiserver的安全通信。以下是这些证书的具体用途和作用：1. Kubernetes 内部组件之间的安全通信
kube-apiserver与kubelet的通信：
kube-apiserver是 Kubernetes 集群的控制中心，而kubelet运行在每个节点上，负责管理该节点上的 Pod 和容器。kube-apiserver和kubelet之间的通信通常使用 HTTPS 加密，以确保传输的数据不会被窃听或篡改。- 这种加密通信需要
kube-apiserver和kubelet之间使用 CA 证书进行相互认证。
kube-apiserver与etcd的通信：
etcd是 Kubernetes 的分布式键值存储，用于存储集群的所有状态信息。kube-apiserver需要与etcd进行加密通信，以确保存储在etcd中的数据的安全性。kube-apiserver使用 TLS 证书与etcd建立安全连接，这需要etcd和kube-apiserver之间信任同一个 CA。
kube-apiserver与kube-controller-manager和kube-scheduler的通信：这些组件也需要通过 HTTPS 与
kube-apiserver进行通信，使用 TLS 证书确保数据的完整性和安全性。2. 保护集群 API 的访问
kube-apiserver对外暴露的 API：kube-apiserver对外暴露的 RESTful API 是集群中所有管理操作的入口，包括kubectl客户端的请求。- 通过使用 TLS 证书，
kube-apiserver可以确保与kubectl等客户端的通信是加密的，防止管理指令被窃听。- 客户端（如
kubectl）通常需要信任kube-apiserver的 CA 证书，以验证kube-apiserver的身份。3. 负载均衡器上的证书
- 负载均衡器上的 TLS 证书：
- 如果在 Kubernetes 高可用集群中配置了负载均衡器（如 HAProxy 或云平台的负载均衡器），负载均衡器也可以配置 TLS 证书，特别是在负载均衡器对外暴露 HTTPS 接口时。
- 负载均衡器上的证书可以用于加密从外部到
kube-apiserver的通信，确保客户端与负载均衡器之间的流量是加密的。- 负载均衡器从客户端接收到 HTTPS 请求后，可以将请求解密并转发给 Kubernetes 内部的
kube-apiserver。4. 总结：TLS 证书的主要用途
内部通信：
kube-apiserver和集群内其他组件（如kubelet、etcd、controller-manager）之间的加密通信，确保传输数据的安全性。- 使用相同的 CA 证书使得集群内的这些组件能够相互认证。
对外暴露的接口：
kube-apiserver对外暴露 API 时，使用 TLS 证书确保与客户端（如kubectl）的通信是安全的。- 如果使用负载均衡器，负载均衡器也可以配置证书，用于加密负载均衡器与客户端之间的通信。
因此，这些证书不仅仅用于集群内部，也在一定程度上用于对外部客户端的认证和加密。尤其是在高可用场景下，为了保证集群的安全性，确保 Kubernetes 内部和外部的通信都是通过 HTTPS 加密进行，从而保护集群中的数据不被泄露和篡改。
在 Kubernetes 集群内部通信中，自签名的证书完全可以满足需求，因此你可以在本地自己生成证书，无需依赖外部的公共证书颁发机构 (CA)。这是因为 Kubernetes 集群的组件（如
kube-apiserver、kubelet、etcd等）只需要彼此之间建立信任关系，并不需要通过外部互联网访问。为什么自签名证书就足够？
内部网络通信：
Kubernetes 集群中的大多数通信都是在内部网络中进行的，比如
kube-apiserver和kubelet、kube-apiserver和etcd之间的通信，这些都是内部的 HTTPS 请求。- 只要在这些组件之间建立了信任关系（例如，通过使用同一个自签名 CA），就能保证数据传输的安全性。
控制信任链：
使用自签名 CA 生成证书，你可以完全控制证书的生成和管理流程。这意味着你可以按照自己的需求生成 CA 和组件的证书，指定有效期和信任关系，灵活性更高。
- 将自签名 CA 的根证书 (
ca.crt) 分发给kube-apiserver、kubelet和etcd，让这些组件信任自签名的 CA 证书，这样就可以在集群内部建立一个自包含的信任链。不依赖外部网络：
由于自签名证书在本地生成，不需要依赖外部的证书颁发机构，尤其适合于私有云或内部部署的 Kubernetes 集群。
- 在内部环境中，使用本地生成的证书还能避免在更新或续期证书时，受到外部网络因素的影响。
什么时候需要外部 CA？
虽然自签名证书在大多数情况下已经足够，但在以下场景中，可能需要考虑使用外部 CA 签发的证书：
从外部访问时需要公信力：
如果你的 Kubernetes API 需要暴露在互联网上，并且需要外部用户或系统通过 HTTPS 访问，那么使用公共 CA 签发的证书可以避免浏览器和其他客户端出现“不受信任的证书”警告。
- 例如，你可能会通过 HTTPS 暴露 Kubernetes 的 API Server 以便在远程管理集群，在这种情况下，使用外部 CA 证书可以提供更好的用户体验。
企业内部统一的证书策略：
在某些企业中，可能有内部的 IT 政策，要求所有的服务都使用由企业内部 CA（如 Active Directory Certificate Services）或其他受信任的证书管理系统颁发的证书。
- 这种情况下，可以使用企业内部的 CA 来签发 Kubernetes 集群所需的证书，符合企业的合规要求。
本地生成证书的方法
如果你决定使用自签名证书，本地生成证书的步骤通常包括：
- 生成自签名 CA：
- 使用
openssl或cfssl生成 CA 证书，用于签发其他组件的证书。- 生成组件的证书：
- 使用自签名的 CA，生成
kube-apiserver、etcd等组件的证书。- 分发 CA 证书：
- 将 CA 证书分发到各个节点，并配置各个组件信任该 CA。
- 配置 Kubernetes 组件使用证书：
- 在每个组件的启动配置中，指定它们使用的证书和 CA。
例如，生成 CA 和自签名证书的常用
openssl命令：```bash
生成 CA 私钥和 CA 证书
openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=kubernetes-ca" -days 10000 -out ca.crt
为 kube-apiserver 生成私钥和证书请求
openssl genrsa -out kube-apiserver.key 2048 openssl req -new -key kube-apiserver.key -subj "/CN=kube-apiserver" -out kube-apiserver.csr
使用 CA 签发 kube-apiserver 的证书
openssl x509 -req -in kube-apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out kube-apiserver.crt -days 10000 ```
将生成的
ca.crt、kube-apiserver.crt和kube-apiserver.key部署到 Kubernetes 组件的相应位置，并在组件启动时指定这些文件。总结
- 自签名证书 在 Kubernetes 集群中广泛使用，尤其是在内部网络中，因为它足够满足内部通信的加密需求，并且可以完全控制证书的颁发和管理。
- 公共 CA 只有在外部访问需要公信力或符合企业合规要求时才需要。
- 本地生成自签名证书的流程较为简单，可以使用
openssl或cfssl等工具来完成。使用自签名证书可以减少对外部服务的依赖，并在配置正确的情况下，提供和公共 CA 类似的加密通信安全。希望这些解释能帮助你更好地理解 Kubernetes 的证书管理！如果有其他问题，随时提问！
在配置 Kubernetes 多 Master 节点的高可用环境时，TLS 证书的正确配置是至关重要的。
kube-apiserver和其他组件（如kubelet、etcd）之间的通信通常通过 HTTPS 进行，因此需要确保所有 Master 节点上的证书一致，且信任同一个 CA（Certificate Authority）。以下是配置 TLS 证书的一般步骤，包括手动生成证书、自动化工具的使用以及负载均衡器的证书配置。1. 手动生成和配置 TLS 证书
如果选择手动管理 TLS 证书，通常需要生成 CA 证书、
kube-apiserver证书和etcd证书。可以使用openssl或cfssl来生成这些证书。步骤 1：生成 CA 证书
首先，生成 CA 的私钥和证书。这个 CA 将用于签发
kube-apiserver和其他组件的证书。
bash openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=kubernetes-ca" -days 10000 -out ca.crt
ca.key是 CA 的私钥。ca.crt是 CA 的证书。步骤 2：生成 API Server 的私钥和证书请求（CSR）
为
kube-apiserver生成私钥和 CSR（Certificate Signing Request）。
bash openssl genrsa -out kube-apiserver.key 2048 openssl req -new -key kube-apiserver.key -subj "/CN=kube-apiserver" -out kube-apiserver.csr \ -config <(cat <<EOF [req] distinguished_name = req_distinguished_name [req_distinguished_name] [ v3_ext ] subjectAltName = @alt_names [alt_names] DNS.1 = kube-apiserver DNS.2 = kube-apiserver.kube-system.svc DNS.3 = kube-apiserver.kube-system.svc.cluster.local DNS.4 = <your-load-balancer-domain> IP.1 = 127.0.0.1 IP.2 = <your-load-balancer-ip> EOF )
kube-apiserver.key是kube-apiserver的私钥。kube-apiserver.csr是kube-apiserver的 CSR 文件。- 在
subjectAltName中需要包含kube-apiserver的 DNS 名称和 IP 地址，以及负载均衡器的域名或 IP 地址。步骤 3：使用 CA 签发
kube-apiserver证书使用 CA 证书对
kube-apiserver.csr进行签名，生成kube-apiserver的证书。
bash openssl x509 -req -in kube-apiserver.csr -CA ca.crt -CAkey ca.key -CAcreateserial \ -out kube-apiserver.crt -days 10000 -extensions v3_ext -extfile <(cat <<EOF [ v3_ext ] subjectAltName = @alt_names [alt_names] DNS.1 = kube-apiserver DNS.2 = kube-apiserver.kube-system.svc DNS.3 = kube-apiserver.kube-system.svc.cluster.local DNS.4 = <your-load-balancer-domain> IP.1 = 127.0.0.1 IP.2 = <your-load-balancer-ip> EOF )
kube-apiserver.crt是签名后的kube-apiserver证书。步骤 4：将证书分发到每个 Master 节点
将生成的以下文件分发到每个 Master 节点：
ca.crtkube-apiserver.crtkube-apiserver.key确保每个 Master 节点的
kube-apiserver使用相同的证书文件。步骤 5：配置
kube-apiserver使用证书在每个 Master 节点的
kube-apiserver启动参数中，指定证书和密钥路径：
bash kube-apiserver \ --advertise-address=<master-ip> \ --tls-cert-file=/path/to/kube-apiserver.crt \ --tls-private-key-file=/path/to/kube-apiserver.key \ --client-ca-file=/path/to/ca.crt \ ...2. 使用
kubeadm生成证书如果使用
kubeadm初始化集群，可以简化证书的生成过程。kubeadm可以自动生成并管理 Kubernetes 所需的证书，并且能够保证所有节点上的证书一致。
- 在使用
kubeadm初始化第一个 Master 节点时，证书会自动生成并存储在/etc/kubernetes/pki/目录下。- 在初始化其他 Master 节点时，可以将第一个节点上的
pki文件夹复制到其他 Master 节点上，以确保所有节点共享相同的证书。```bash
在 master1 上
scp -r /etc/kubernetes/pki user@master2:/etc/kubernetes/ scp -r /etc/kubernetes/pki user@master3:/etc/kubernetes/ ```
然后使用
kubeadm join命令在其他 Master 节点上加入集群即可。3. 自动化证书管理 - 使用
cert-manager如果需要自动化证书的管理，可以使用
cert-manager这个 Kubernetes 内部的证书管理工具。
cert-manager可以自动生成和管理 Kubernetes 集群内部的证书，并支持多种证书颁发机构（如 Let's Encrypt、内部 CA）。安装
cert-manager
- 安装
cert-manager：
bash kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml2. 创建一个ClusterIssuer对象，使用cert-manager颁发 CA 签发的证书。创建一个名为
ca-issuer.yaml的文件：
yaml apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: ca-issuer spec: ca: secretName: ca-secret3. 创建 CA 秘钥并存储为 Kubernetes Secret：
bash kubectl create secret tls ca-secret --cert=ca.crt --key=ca.key -n cert-manager4. 创建Certificate对象来自动颁发证书：
yaml apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: kube-apiserver-cert namespace: kube-system spec: secretName: kube-apiserver-tls issuerRef: name: ca-issuer kind: ClusterIssuer commonName: kube-apiserver dnsNames: - kube-apiserver - <your-load-balancer-domain> ipAddresses: - <your-load-balancer-ip> - 127.0.0.15.cert-manager会自动生成和更新kube-apiserver所需的证书，并将其存储在kube-system命名空间中的kube-apiserver-tlsSecret 中。4. 为负载均衡器配置通配符证书
如果你使用的是 HTTPS 负载均衡器，可以为负载均衡器配置一个通配符证书，确保负载均衡器和
kube-apiserver之间的通信是加密的。
- 可以使用 Let's Encrypt 或 商业 CA 来签发通配符证书。
- 将生成的证书和密钥上传到负载均衡器，并配置负载均衡器监听 HTTPS 请求。
Nginx 或 HAProxy 的 SSL 配置示例（简化）
对于 HAProxy，可以在配置中添加证书路径来启用 HTTPS：
haproxy frontend kubernetes-api bind *:6443 ssl crt /etc/ssl/certs/kubernetes.pem mode tcp default_backend kubernetes-api-backend
/etc/ssl/certs/kubernetes.pem是包含了kube-apiserver证书、密钥和 CA 的 PEM 格式文件。总结
- 手动配置证书：适合对证书管理有特殊需求的环境，需要手动生成 CA 和
kube-apiserver证书，并确保所有 Master 节点使用相同的证书。- 使用
kubeadm：简化证书管理，适合使用kubeadm初始化和扩展 Kubernetes 集群的场景。- 使用
cert-manager：自动化证书管理，适合希望在 Kubernetes 内部管理证书并自动更新的场景。- **负载均衡器
5.2.6 备份与还原
这个过程并不会自动备份其他如节点上的容器数据（如应用程序本身的数据），它只是用来保障 Kubernetes 集群配置和状态信息的恢复。如果你需要更全面的数据保护，还需要为工作负载中的应用程序和存储卷设置相应的数据备份策略。
在 Kubernetes 中，
etcd存储了所有 API 对象的数据，包括节点信息、Pod、ConfigMap、Secrets 等。由于etcd集群的高可用性依赖于分布式数据存储，但任何配置错误、硬件故障或者人为操作失误等都可能导致数据丢失或损坏。因此，即便etcd自身具备高可用特性，定期备份和还原etcd数据 仍然是非常重要的，这是确保集群在故障后可以恢复到正常状态的关键步骤。总结来说，这个备份和还原过程专注于：
- 备份 etcd 数据 ：创建
etcd的快照，以确保 Kubernetes 集群状态能够在需要时恢复。- 还原 etcd 数据 ：在集群发生重大故障时，从快照中恢复
etcd，以确保 Kubernetes 集群能够正常恢复运行。1. 安装 etcdctl 工具
etcdctl工具是etcd的命令行客户端，用于管理和备份等操作。可以通过以下方式安装etcdctl：```bash
安装 etcdctl
apt-get install etcd-client # Ubuntu yum install etcd -y # CentOS ```
或者通过二进制方式直接下载
etcd，解压缩后，etcdctl通常与etcd放在同一个目录中。2. 备份 etcd 数据
etcdctl工具可以用来创建集群状态的快照备份，以下是具体的备份命令：```bash
使用 etcdctl 进行 etcd 数据快照备份
etcdctl --endpoints="http://127.0.0.1:2379" snapshot save /path/to/backup.db ```
在备份过程中，请确保以下参数正确：
- --endpoints：设置
etcd的访问地址和端口（例如http://127.0.0.1:2379），需要根据实际情况修改。- /path/to/backup.db：保存备份快照的路径，可以是你希望存放备份文件的本地路径。
此外，推荐定期通过
cron定时任务进行自动备份，例如，每天凌晨 1 点备份一次：```bash
创建 cron 任务，执行备份操作
0 1 * * * etcdctl --endpoints="http://127.0.0.1:2379" snapshot save /backups/etcd/backup-$(date +\%Y-\%m-\%d).db ```
3. 备份存储管理
定期备份的数据应该尽量存放在异地安全位置，以防止集群的重大故障导致数据完全丢失。可以考虑使用以下方式进行备份存储管理：
- 使用
rsync定期同步备份文件到远程服务器。- 将备份文件推送到对象存储（例如 AWS S3 或阿里云 OSS）。
- 通过
scp命令将备份文件复制到异地服务器。例如，通过
rsync将备份推送到远程服务器：
bash rsync -av /backups/etcd/backup-*.db user@remote-server:/remote/backups/4. 恢复 etcd 数据
在发生重大故障时，可以通过快照数据恢复
etcd集群状态。以下是恢复etcd的具体步骤：4.1 停止 etcd 服务
在恢复之前，首先停止正在运行的
etcd服务，以免覆盖现有数据：
bash systemctl stop etcd4.2 从快照文件恢复数据
可以使用
etcdctl snapshot restore命令从快照文件恢复etcd数据，以下是恢复命令：
bash etcdctl snapshot restore /path/to/backup.db --name <etcd-node-name> --initial-cluster <initial-cluster> --initial-advertise-peer-urls <initial-advertise-peer-urls>参数说明：
- /path/to/backup.db：备份文件的路径。
- --name
<etcd-node-name>：要恢复的etcd节点的名称，应与原来的名称一致。- --initial-cluster
<initial-cluster>：集群的初始成员列表，格式为<name>=<url>，例如etcd1=http://127.0.0.1:2380,etcd2=http://192.168.0.2:2380。- --initial-advertise-peer-urls
<initial-advertise-peer-urls>：该节点对外提供的服务地址，例如http://127.0.0.1:2380。例如：
bash etcdctl snapshot restore /backups/etcd/backup-2024-10-17.db \ --name etcd-node1 \ --initial-cluster etcd-node1=http://127.0.0.1:2380 \ --initial-advertise-peer-urls http://127.0.0.1:23804.3 重置数据目录
恢复完成后，可以将恢复的数据目录替换为
etcd的数据目录。例如，将恢复的数据放置到/var/lib/etcd目录中：
bash mv /path/to/restored-data-dir /var/lib/etcd4.4 启动 etcd 服务
恢复完成后，可以重新启动
etcd服务：
bash systemctl start etcd5. 检查恢复状态
恢复完成后，可以通过
etcdctl工具查看集群状态，确保恢复成功：
bash etcdctl --endpoints="http://127.0.0.1:2379" endpoint status确认
etcd集群所有节点的状态和数据都正常同步后，即可重新启用集群。总结
- 备份：使用
etcdctl snapshot save命令定期进行快照备份，并存储到异地。- 恢复：使用
etcdctl snapshot restore命令恢复数据，确保备份文件安全有效。- 定期检查：定期检查
etcd的健康状态，以便尽早发现并解决问题。如果有任何其他问题或需要进一步的帮助，欢迎继续提问。
5.2.7 时间同步
在分布式系统中，时间同步 对于日志分析、调试、以及 etcd 的一致性协议（如 Raft）是非常重要的。建议在所有 Master 节点和 etcd 节点上配置 NTP（Network Time Protocol），以确保时间一致。
sudo apt install ntp
sudo systemctl enable ntp
sudo systemctl start ntp
5.2.8. Leader Election（领导选举）
在多 Master 节点配置中，kube-scheduler 和 kube-controller-manager 都需要启用 Leader Election 模式，以确保同一时刻只有一个活跃的 scheduler 和 controller-manager，避免资源争夺和重复操作。
kube-scheduler和kube-controller-manager的配置中，需要启用--leader-elect=true参数（默认是启用的）：bash kube-controller-manager --leader-elect=true kube-scheduler --leader-elect=true
Leader Election 的机制保证了在某个 Master 节点故障时，其他节点可以自动选举出新的领导者来继续工作。
5.2.9. 灾难恢复策略
在配置高可用集群时，除了冗余部署，还需要制定详细的灾难恢复策略，以应对集群的部分或全部失效。
- Master 节点恢复步骤：需要测试如何在现有的高可用环境中添加新的 Master 节点，或在某个 Master 节点失效后进行替换。
- etcd 节点的恢复：掌握如何在
etcd节点失效时，通过备份数据进行恢复，并重新加入到集群中。 - 日志管理：通过 ELK（Elasticsearch, Logstash, Kibana）等日志管理工具，收集和监控 Master 节点和
etcd的日志，便于故障诊断和恢复。