计算机网络以及路由交换协议与Kubernetes架构的相同之处
1. 核心组件对照
计算机网络与路由交换 Kubernetes 架构 对应关系说明
路由器（Router） kube-apiserver 路由器负责在不同网络之间转发数据包，而 kube-apiserver 是 Kubernetes 的核心组件，负责接收和处理所有 API 请求。
交换机（Switch） kube-scheduler 交换机负责在局域网内转发数据包，而 kube-scheduler 负责将 Pod 调度到合适的节点上。
路由表（Routing Table） etcd 路由表存储网络的路由信息，而 etcd 存储 Kubernetes 集群的所有状态和配置信息。
ARP 协议（地址解析协议） kubelet ARP 协议用于将 IP 地址解析为 MAC 地址，而 kubelet 负责将 Pod 的配置信息解析为实际的容器运行状态。
BGP/OSPF 协议（路由协议） kube-proxy BGP/OSPF 协议用于动态学习和分发路由信息，而 kube-proxy 负责动态维护 Service 的 IP 和端口转发规则。
防火墙（Firewall） NetworkPolicy 防火墙用于控制网络流量，而 NetworkPolicy 用于控制 Pod 之间的网络通信。
2. 网络模型对照
计算机网络与路由交换 Kubernetes 架构 对应关系说明
IP 地址（IP Address） Pod IP IP 地址用于标识网络中的设备，而 Pod IP 用于标识 Kubernetes 集群中的 Pod。
子网（Subnet） Namespace 子网用于划分网络，而 Namespace 用于划分 Kubernetes 集群中的资源。
VLAN（虚拟局域网） Network Policy VLAN 用于隔离网络流量，而 Network Policy 用于隔离 Pod 之间的网络通信。
NAT（网络地址转换） Service NAT 用于将私有 IP 地址映射为公有 IP 地址，而 Service 用于将 Pod IP 映射为集群内外的访问地址。
负载均衡（Load Balancer） Ingress 负载均衡用于分发网络流量，而 Ingress 用于分发外部流量到集群内的 Service。
3. 部署与运维对照
计算机网络与路由交换 Kubernetes 架构 对应关系说明
静态路由配置 静态 Pod 配置 静态路由需要手动配置，而静态 Pod 通过配置文件直接部署在节点上。
动态路由协议（如 BGP） 动态调度与扩展 动态路由协议自动学习和更新路由信息，而 Kubernetes 动态调度 Pod 并根据负载自动扩展。
网络监控（如 SNMP） 监控与日志（如 Prometheus） 网络监控用于收集和分析网络状态，而 Kubernetes 使用 Prometheus 等工具监控集群状态。
故障切换（Failover） Pod 重启与节点故障恢复 故障切换用于在网络设备故障时切换到备用设备，而 Kubernetes 在 Pod 或节点故障时自动重启或重新调度。
4. 总结思维图 计算机网络与路由交换 Kubernetes 架构
------------------------------- -------------------------------
路由器 (Router) kube-apiserver (API 网关)
交换机 (Switch) kube-scheduler (调度器)
路由表 (Routing Table) etcd (状态存储)
ARP 协议 (地址解析) kubelet (节点代理)
BGP/OSPF 协议 (路由协议) kube-proxy (网络代理)
防火墙 (Firewall) NetworkPolicy (网络策略)
IP 地址 (IP Address) Pod IP (Pod 地址)
子网 (Subnet) Namespace (命名空间)
VLAN (虚拟局域网) Network Policy (网络策略)
NAT (网络地址转换) Service (服务)
负载均衡 (Load Balancer) Ingress (入口)
静态路由配置 静态 Pod 配置
动态路由协议 (如 BGP) 动态调度与扩展
网络监控 (如 SNMP) 监控与日志 (如 Prometheus)
故障切换 (Failover) Pod 重启与节点故障恢复
5. 关键点总结
核心组件 ：
Kubernetes 的核心组件（如 kube-apiserver、kube-scheduler、etcd）与网络设备（如路由器、交换机、路由表）在功能上高度相似，都是负责信息传递和决策。
网络模型 ：
Kubernetes 的网络模型（如 Pod IP、Service、Ingress）与计算机网络中的 IP 地址、NAT、负载均衡等概念一一对应。
部署与运维 ：
Kubernetes 的动态调度、监控和故障恢复机制与网络中的动态路由、监控和故障切换机制类似，都是为了提高系统的可用性和可靠性。
1. 分层架构
计算机网络与路由交换 Kubernetes 架构 对应关系说明
OSI 七层模型 Kubernetes 分层架构 OSI 模型将网络通信分为七层，而 Kubernetes 的架构也可以分为控制层、数据层和应用层，每层各司其职。
物理层（Physical Layer） 节点（Node） 物理层负责传输原始比特流，而节点是 Kubernetes 中运行容器的物理或虚拟机。
数据链路层（Data Link Layer） CNI（容器网络接口） 数据链路层负责帧的传输，而 CNI 负责 Pod 之间的网络通信。
网络层（Network Layer） Service 和 Ingress 网络层负责 IP 地址和路由，而 Service 和 Ingress 负责 Pod 的网络访问和流量分发。
传输层（Transport Layer） kube-proxy 传输层负责端到端的通信（如 TCP/UDP），而 kube-proxy 负责 Service 的端口转发和负载均衡。
应用层（Application Layer） Pod 和容器 应用层负责具体的应用协议（如 HTTP），而 Pod 和容器是 Kubernetes 中运行应用的实体。
2. 协议与通信
计算机网络与路由交换 Kubernetes 架构 对应关系说明
TCP/IP 协议栈 Kubernetes API 通信 TCP/IP 协议栈是网络通信的基础，而 Kubernetes 的组件通过 API 进行通信和协调。
HTTP/HTTPS 协议 kube-apiserver 的 REST API HTTP/HTTPS 是 Web 通信的标准协议，而 kube-apiserver 通过 REST API 提供集群的管理接口。
DNS（域名解析系统） CoreDNS DNS 用于将域名解析为 IP 地址，而 CoreDNS 是 Kubernetes 中用于服务发现的默认 DNS 组件。
ARP（地址解析协议） kubelet 的 Pod 状态同步 ARP 用于将 IP 地址解析为 MAC 地址，而 kubelet 负责将 Pod 的期望状态同步为实际状态。
3. 安全机制
计算机网络与路由交换 Kubernetes 架构 对应关系说明
防火墙（Firewall） NetworkPolicy 防火墙用于控制网络流量，而 NetworkPolicy 用于控制 Pod 之间的网络通信。
VPN（虚拟专用网络） Service Mesh（如 Istio） VPN 用于加密和隔离网络通信，而 Service Mesh 提供了 Pod 之间的安全通信和流量管理。
TLS/SSL 加密 Kubernetes 的证书管理 TLS/SSL 用于加密网络通信，而 Kubernetes 使用证书管理来保护 API 通信和组件之间的交互。
ACL（访问控制列表） RBAC（基于角色的访问控制） ACL 用于控制网络访问权限，而 RBAC 用于控制用户和服务账户对 Kubernetes 资源的访问权限。
4. 扩展性与高可用
计算机网络与路由交换 Kubernetes 架构 对应关系说明
路由器的冗余设计 kube-apiserver 的高可用 路由器通过冗余设计提高可用性，而 kube-apiserver 通过多实例部署实现高可用。
交换机的堆叠技术 etcd 的集群部署 交换机的堆叠技术用于扩展带宽和冗余，而 etcd 通过集群部署实现数据的高可用和一致性。
负载均衡器（Load Balancer） Ingress Controller 负载均衡器用于分发流量，而 Ingress Controller 用于分发外部流量到集群内的 Service。
动态路由协议（如 BGP） Pod 的动态调度与扩展 动态路由协议用于自动学习和更新路由信息，而 Kubernetes 动态调度 Pod 并根据负载自动扩展。
5. 故障排查与监控
计算机网络与路由交换 Kubernetes 架构 对应关系说明
Ping 和 Traceroute kubectl describe 和 logs Ping 和 Traceroute 用于排查网络连通性问题，而 kubectl describe 和 logs 用于排查 Pod 和节点的状态问题。
SNMP（简单网络管理协议） Prometheus 和 Grafana SNMP 用于监控网络设备的状态，而 Prometheus 和 Grafana 用于监控 Kubernetes 集群的状态。
NetFlow（流量分析） kube-proxy 的流量统计 NetFlow 用于分析网络流量，而 kube-proxy 负责统计和转发 Service 的流量。
Syslog（系统日志） Fluentd 和 Elasticsearch Syslog 用于收集网络设备的日志，而 Fluentd 和 Elasticsearch 用于收集和分析 Kubernetes 的日志。
6. 总结思维图 计算机网络与路由交换 Kubernetes 架构
------------------------------- -------------------------------
OSI 七层模型 Kubernetes 分层架构
物理层 (Physical Layer) 节点 (Node)
数据链路层 (Data Link Layer) CNI (容器网络接口)
网络层 (Network Layer) Service 和 Ingress
传输层 (Transport Layer) kube-proxy
应用层 (Application Layer) Pod 和容器
TCP/IP 协议栈 Kubernetes API 通信
HTTP/HTTPS 协议 kube-apiserver 的 REST API
DNS (域名解析系统) CoreDNS
ARP (地址解析协议) kubelet 的 Pod 状态同步
防火墙 (Firewall) NetworkPolicy
VPN (虚拟专用网络) Service Mesh (如 Istio)
TLS/SSL 加密 Kubernetes 的证书管理
ACL (访问控制列表) RBAC (基于角色的访问控制)
路由器的冗余设计 kube-apiserver 的高可用
交换机的堆叠技术 etcd 的集群部署
负载均衡器 (Load Balancer) Ingress Controller
动态路由协议 (如 BGP) Pod 的动态调度与扩展
Ping 和 Traceroute kubectl describe 和 logs
SNMP (简单网络管理协议) Prometheus 和 Grafana
NetFlow (流量分析) kube-proxy 的流量统计
Syslog (系统日志) Fluentd 和 Elasticsearch
7. 关键点总结
分层架构 ：
Kubernetes 的分层架构与 OSI 七层模型类似，每层都有明确的职责和功能。
协议与通信 ：
Kubernetes 的组件通过 API 进行通信，类似于网络中的协议栈。
安全机制 ：
Kubernetes 提供了多种安全机制（如 NetworkPolicy、RBAC），类似于网络中的防火墙和 VPN。
扩展性与高可用 ：
Kubernetes 通过动态调度、集群部署和负载均衡实现扩展性和高可用，类似于网络中的冗余设计和动态路由。
故障排查与监控 ：
Kubernetes 提供了丰富的工具（如 kubectl、Prometheus）用于故障排查和监控，类似于网络中的 Ping、SNMP 和 Syslog。
Namespace应用场景与原理
1. 什么是 Namespace？
Namespace 是 Kubernetes 中用于资源隔离和组织的逻辑分区。它允许在同一个集群中创建多个虚拟集群，每个 Namespace 中的资源名称可以重复，但跨 Namespace 的资源名称必须唯一。
默认情况下，Kubernetes 提供了几个内置的 Namespace，如 default、kube-system 和 kube-public。
2. Namespace 的原理
资源隔离 ：
Namespace 将集群资源（如 Pod、Service、Deployment 等）隔离到不同的逻辑分区中。
不同 Namespace 中的资源相互独立，无法直接访问。
资源配额 ：
可以为每个 Namespace 设置资源配额（Resource Quota），限制其使用的 CPU、内存、存储等资源。
权限控制 ：
使用 RBAC（基于角色的访问控制）可以为不同 Namespace 分配不同的权限，实现细粒度的访问控制。
网络隔离 ：
默认情况下，不同 Namespace 中的 Pod 可以通过 Service 名称相互访问。
如果需要更严格的网络隔离，可以使用网络策略（Network Policy）限制跨 Namespace 的流量。
3. Namespace 的应用场景
多租户环境 ：
在同一个集群中为不同的团队或客户分配独立的 Namespace，实现资源隔离和权限控制。
环境隔离 ：
将开发、测试和生产环境部署到不同的 Namespace，避免环境之间的干扰。
资源管理 ：
通过资源配额限制每个 Namespace 的资源使用，防止资源耗尽。
权限管理 ：
为不同团队或用户分配不同的 Namespace 权限，确保安全性和合规性。
应用隔离 ：
将不同的应用部署到不同的 Namespace，便于管理和维护。
4. Namespace 的应用案例 案例 1：多租户环境
场景 ：一个公司有多个团队（如开发团队、测试团队、运维团队），每个团队需要独立的 Kubernetes 环境。解决方案 ：
为每个团队创建一个 Namespace：kubectl create namespace dev
kubectl create namespace test
kubectl create namespace ops
为每个 Namespace 设置资源配额：apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
为每个团队分配权限：apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-team-binding
namespace: dev
subjects:
- kind: Group
name: dev-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: dev-role
apiGroup: rbac.authorization.k8s.io
案例 2：环境隔离
场景 ：一个应用需要在开发、测试和生产环境中部署，确保环境之间互不干扰。解决方案 ：
为每个环境创建一个 Namespace：kubectl create namespace dev
kubectl create namespace test
kubectl create namespace prod
在每个 Namespace 中部署应用：kubectl apply -f app.yaml -n dev
kubectl apply -f app.yaml -n test
kubectl apply -f app.yaml -n prod
使用不同的配置文件和资源配额管理每个环境。
案例 3：资源管理
场景 ：一个集群中有多个应用，需要限制每个应用的资源使用。解决方案 ：
为每个应用创建一个 Namespace：kubectl create namespace app1
kubectl create namespace app2
为每个 Namespace 设置资源配额：apiVersion: v1
kind: ResourceQuota
metadata:
name: app1-quota
namespace: app1
spec:
hard:
requests.cpu: "5"
requests.memory: "10Gi"
limits.cpu: "10"
limits.memory: "20Gi"
监控每个 Namespace 的资源使用情况：kubectl describe resourcequota app1-quota -n app1
案例 4：权限管理
场景 ：一个公司有多个部门，每个部门需要访问不同的 Kubernetes 资源。解决方案 ：
为每个部门创建一个 Namespace：kubectl create namespace finance
kubectl create namespace hr
为每个部门分配权限：apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: finance-team-binding
namespace: finance
subjects:
- kind: Group
name: finance-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: finance-role
apiGroup: rbac.authorization.k8s.io
确保每个部门只能访问其 Namespace 中的资源。
5. 注意事项
资源隔离 ：
Namespace 只能隔离 Kubernetes 资源，不能隔离节点或物理资源。
网络隔离 ：
默认情况下，不同 Namespace 中的 Pod 可以通过 Service 名称相互访问，需要使用网络策略实现更严格的隔离。
资源配额 ：
资源配额只能限制 Namespace 中的资源使用，不能限制集群级别的资源使用。
权限管理 ：
使用 RBAC 时，确保为每个 Namespace 分配正确的权限，避免权限泄露。
Namespace 资源配额
1. 启用资源配额 什么是资源配额？
资源配额（Resource Quota） 是 Kubernetes 中用于限制 Namespace 资源使用的一种机制。它可以限制 Namespace 中的计算资源（如 CPU、内存）、存储资源（如存储卷、持久卷）和对象数量（如 Pod、Service）。
启用资源配额
创建 Namespace ：kubectl create namespace my-namespace
创建 ResourceQuota 资源 ：apiVersion: v1
kind: ResourceQuota
metadata:
name: my-quota
namespace: my-namespace
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
requests.storage: "100Gi"
persistentvolumeclaims: "10"
pods: "50"
services: "10"
应用 ResourceQuota ：kubectl apply -f quota.yaml
2. 计算资源配额 支持的资源类型
CPU ：
requests.cpu：请求的 CPU 资源。limits.cpu：CPU 资源上限。
内存 ：
requests.memory：请求的内存资源。limits.memory：内存资源上限。
示例 apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-quota
namespace: my-namespace
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
验证配额 kubectl describe resourcequota compute-quota -n my-namespace
3. 存储资源配额 支持的资源类型
存储请求 ：
requests.storage：请求的存储资源。
持久卷声明 ：
persistentvolumeclaims：持久卷声明的数量。
存储类 ：
requests.storageclass.storage.k8s.io/<storage-class-name>：特定存储类的存储请求。
示例 apiVersion: v1
kind: ResourceQuota
metadata:
name: storage-quota
namespace: my-namespace
spec:
hard:
requests.storage: "100Gi"
persistentvolumeclaims: "10"
requests.storageclass.storage.k8s.io/ssd: "50Gi"
验证配额 kubectl describe resourcequota storage-quota -n my-namespace
4. 对象数据配额 支持的资源类型
Pod ：
Service ：
ConfigMap ：
configmaps：ConfigMap 的数量。
Secret ：
ReplicationController ：
replicationcontrollers：ReplicationController 的数量。
Deployment ：
deployments.apps：Deployment 的数量。
StatefulSet ：
statefulsets.apps：StatefulSet 的数量。
Job ：
CronJob ：
cronjobs.batch：CronJob 的数量。
示例 apiVersion: v1
kind: ResourceQuota
metadata:
name: object-quota
namespace: my-namespace
spec:
hard:
pods: "50"
services: "10"
configmaps: "20"
secrets: "10"
deployments.apps: "5"
statefulsets.apps: "3"
jobs.batch: "10"
cronjobs.batch: "5"
验证配额 kubectl describe resourcequota object-quota -n my-namespace
5. 综合示例 apiVersion: v1
kind: ResourceQuota
metadata:
name: comprehensive-quota
namespace: my-namespace
spec:
hard:
requests.cpu: "10"
requests.memory: "20Gi"
limits.cpu: "20"
limits.memory: "40Gi"
requests.storage: "100Gi"
persistentvolumeclaims: "10"
pods: "50"
services: "10"
configmaps: "20"
secrets: "10"
deployments.apps: "5"
statefulsets.apps: "3"
jobs.batch: "10"
cronjobs.batch: "5"
6. 注意事项
配额限制 ：
资源配额只能限制 Namespace 中的资源使用，不能限制集群级别的资源使用。
配额更新 ：
更新 ResourceQuota 时，需要确保新的配额不会导致现有资源超出限制。
配额监控 ：
定期监控资源配额的使用情况，及时调整配额以避免资源耗尽。
配额冲突 ：
如果多个 ResourceQuota 资源对同一资源类型设置了不同的限制，Kubernetes 会取最小值作为实际限制。
Kubernetes Label
1. Label 的基本概念
Label 是 Kubernetes 中用于标识和分类资源的键值对。Label 可以附加到任何 Kubernetes 资源（如 Pod、Service、Node 等）上，用于查询、筛选和组织资源。
Label 的键和值必须是字符串，且长度不超过 63 个字符。
2. Label 的使用场景
资源分类 ：
使用 Label 对资源进行分类，如环境（dev、test、prod）、应用（app1、app2）、团队（team1、team2）等。
资源筛选 ：
使用 Label 筛选资源，如查询特定环境或应用的所有 Pod。
资源关联 ：
使用 Label 关联资源，如将 Service 与特定 Pod 关联。
资源调度 ：
使用 Label 控制 Pod 的调度，如将 Pod 调度到特定节点。
3. Label 的实战案例 案例 1：资源分类
场景 ：一个集群中有多个应用（app1、app2）和多个环境（dev、test、prod），需要对这些资源进行分类。解决方案 ：
为 Pod 添加 Label：apiVersion: v1
kind: Pod
metadata:
name: app1-dev
labels:
app: app1
env: dev
spec:
containers:
- name: app1
image: nginx
查询特定环境或应用的所有 Pod：kubectl get pods -l env =dev
kubectl get pods -l app=app1
案例 2：资源筛选
场景 ：一个集群中有多个团队（team1、team2），需要查询特定团队的所有资源。解决方案 ：
为资源添加 Label：apiVersion: v1
kind: Pod
metadata:
name: team1-pod
labels:
team: team1
spec:
containers:
- name: team1
image: nginx
查询特定团队的所有资源：kubectl get all -l team=team1
案例 3：资源关联
场景 ：一个 Service 需要关联特定 Label 的 Pod。解决方案 ：
为 Pod 添加 Label：apiVersion: v1
kind: Pod
metadata:
name: app1-pod
labels:
app: app1
spec:
containers:
- name: app1
image: nginx
创建 Service 并关联 Label：apiVersion: v1
kind: Service
metadata:
name: app1-service
spec:
selector:
app: app1
ports:
- protocol: TCP
port: 80
targetPort: 80
案例 4：资源调度
场景 ：一个 Pod 需要调度到特定 Label 的节点。解决方案 ：
为节点添加 Label：kubectl label node <node-name> disk=ssd
创建 Pod 并指定节点选择器：apiVersion: v1
kind: Pod
metadata:
name: ssd-pod
spec:
containers:
- name: ssd
image: nginx
nodeSelector:
disk: ssd
4. Label 的高级用法 案例 5：多条件筛选 案例 6：正则表达式筛选 案例 7：Label 的增删改查
添加 Label ：kubectl label pod app1-pod version=v1
删除 Label ：kubectl label pod app1-pod version-
修改 Label ：kubectl label pod app1-pod version=v2 --overwrite
查看 Label ：kubectl get pod app1-pod --show-labels
5. 注意事项
Label 命名规范 ：
Label 的键和值必须符合 DNS 子域名的命名规范，且长度不超过 63 个字符。
Label 的唯一性 ：
Label 的键在同一个资源中必须唯一，但不同资源可以使用相同的键。
Label 的查询性能 ：
使用 Label 查询资源时，Kubernetes 会对所有资源进行扫描，因此在大规模集群中可能会影响性能。
Label 的维护 ：
Pod
1. Pod 的基本概念
Pod 是 Kubernetes 中最小的部署单元，包含一个或多个容器。同一个 Pod 中的容器共享网络和存储资源，可以通过 localhost 相互通信。
Pod 是短暂的，Kubernetes 会根据需要创建、销毁和重新调度 Pod。
每个 Pod 都有一个唯一的 IP 地址，但在 Pod 重启或重新调度时可能会发生变化。
2. Pod 的工作方式
调度 ：
Kubernetes 调度器将 Pod 分配到合适的节点上运行。
运行 ：
节点上的 Kubelet 负责启动和管理 Pod 中的容器。
监控 ：
Kubelet 会监控 Pod 的状态，并在 Pod 失败时重新启动容器。
销毁 ：
当 Pod 不再需要时，Kubernetes 会将其销毁并释放资源。
3. 创建和删除 Pod 创建 Pod
使用 kubectl run 命令 ：kubectl run my-pod --image=nginx
使用 YAML 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
kubectl apply -f pod.yaml
删除 Pod
使用 kubectl delete 命令 ：kubectl delete pod my-pod
使用 YAML 配置文件 ：kubectl delete -f pod.yaml
4. 以配置文件方式创建静态 Pod 什么是静态 Pod？
静态 Pod 是由节点上的 Kubelet 直接管理的 Pod，不通过 Kubernetes API Server。静态 Pod 的配置文件通常放在节点的特定目录中，Kubelet 会定期检查该目录并创建或更新 Pod。
创建静态 Pod
在节点上创建配置文件 ：sudo vi /etc/kubernetes/manifests/static-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: static-pod
spec:
containers:
- name: nginx
image: nginx
Kubelet 自动创建 Pod ：
Kubelet 会定期检查 /etc/kubernetes/manifests 目录，并创建或更新 Pod。
查看静态 Pod ：kubectl get pods
static-pod-<node-name>。
删除静态 Pod
删除配置文件 ：sudo rm /etc/kubernetes/manifests/static-pod.yaml
Kubelet 自动删除 Pod ：
Kubelet 会检测到配置文件被删除，并删除对应的 Pod。
5. 以 HTTP 创建静态 Pod 配置 Kubelet
修改 Kubelet 配置文件 ：sudo vi /var/lib/kubelet/config.yaml
staticPodPath: /etc/kubernetes/manifests
staticPodURL: http://<server-ip>/manifests
重启 Kubelet ：sudo systemctl restart kubelet
创建静态 Pod
在 HTTP 服务器上放置配置文件 ：
在 HTTP 服务器的 /manifests 目录下放置 static-pod.yaml 文件。
Kubelet 自动创建 Pod ：
Kubelet 会从 HTTP 服务器下载配置文件，并创建或更新 Pod。
查看静态 Pod ：kubectl get pods
删除静态 Pod
从 HTTP 服务器删除配置文件 ：
删除 HTTP 服务器上的 static-pod.yaml 文件。
Kubelet 自动删除 Pod ：
Kubelet 会检测到配置文件被删除，并删除对应的 Pod。
6. 注意事项
Pod 的生命周期 ：
Pod 是短暂的，Kubernetes 会根据需要创建、销毁和重新调度 Pod。
静态 Pod 的管理 ：
静态 Pod 由 Kubelet 直接管理，不通过 Kubernetes API Server，因此无法使用 kubectl 命令直接管理。
Pod 的网络和存储 ：
同一个 Pod 中的容器共享网络和存储资源，可以通过 localhost 相互通信。
Pod 的资源限制 ：
可以为 Pod 设置资源请求和限制，确保其不会占用过多资源。
Pod 资源限制
1. Pod 资源限制 什么是资源限制？
资源限制 是 Kubernetes 中用于限制 Pod 使用的 CPU 和内存资源的机制。资源限制包括 请求（requests） 和 上限（limits） ：
请求 ：Pod 启动时所需的最小资源。上限 ：Pod 可以使用的最大资源。
设置资源限制
在 Pod 配置文件中设置 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
应用配置文件 ：kubectl apply -f pod.yaml
验证资源限制 ：kubectl describe pod my-pod
Limits:
cpu: 500m
memory: 128Mi
Requests:
cpu: 250m
memory: 64Mi
2. 根据 Node 节点名称进行 Pod 资源调度 什么是节点名称调度？
节点名称调度 是将 Pod 调度到指定节点的一种方式。通过 nodeName 字段指定目标节点的名称。
设置节点名称调度
在 Pod 配置文件中设置 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
nodeName: <node-name>
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f pod.yaml
验证调度结果 ：kubectl get pod my-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-pod 1 /1 Running 0 10 s 10.244 .1.2 <node-name >
3. 根据 Node 节点标签进行调度 什么是节点标签调度？
节点标签调度 是将 Pod 调度到具有特定标签的节点的一种方式。通过 nodeSelector 字段指定目标节点的标签。
设置节点标签调度
为节点添加标签 ：kubectl label node <node-name> disk=ssd
在 Pod 配置文件中设置 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
nodeSelector:
disk: ssd
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f pod.yaml
验证调度结果 ：kubectl get pod my-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-pod 1 /1 Running 0 10 s 10.244 .1.2 <node-name >
4. 高级调度策略 节点亲和性（Node Affinity）
节点亲和性 是一种更灵活的调度策略，允许根据节点的标签和条件进行调度。支持 requiredDuringSchedulingIgnoredDuringExecution（必须满足）和 preferredDuringSchedulingIgnoredDuringExecution（优先满足）两种模式。
设置节点亲和性
在 Pod 配置文件中设置 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f pod.yaml
验证调度结果 ：kubectl get pod my-pod -o wide
5. 注意事项
资源限制的合理性 ：
设置资源请求和上限时，确保其合理，避免资源浪费或 Pod 无法启动。
节点名称调期的局限性 ：
节点名称调度是一种硬性调度策略，如果目标节点不可用，Pod 将无法启动。
节点标签调期的灵活性 ：
节点标签调度是一种灵活的调度策略，可以根据节点的标签动态选择目标节点。
节点亲和性的复杂性 ：
节点亲和性提供了更复杂的调度策略，但配置和管理也相对复杂。
Node 节点亲和性
1. Node 节点亲和性 什么是节点亲和性？
节点亲和性（Node Affinity） 是 Kubernetes 中用于控制 Pod 调度到特定节点的一种机制。它允许根据节点的标签和条件进行调度，支持 硬亲和性（Required） 和 软亲和性（Preferred） 两种模式。
节点亲和性的类型
硬亲和性（Required） ：
Pod 必须调度到满足条件的节点上，否则无法启动。
软亲和性（Preferred） ：
Pod 优先调度到满足条件的节点上，但如果条件不满足，仍然可以调度到其他节点。
2. 硬亲和性实战 场景
一个 Pod 必须调度到具有 disk=ssd 标签的节点上。
步骤
为节点添加标签 ：kubectl label node <node-name> disk=ssd
在 Pod 配置文件中设置硬亲和性 ：apiVersion: v1
kind: Pod
metadata:
name: hard-affinity-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f hard-affinity-pod.yaml
验证调度结果 ：kubectl get pod hard-affinity-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
hard-affinity-pod 1 /1 Running 0 10 s 10.244 .1.2 <node-name >
3. 软亲和性实战 场景
一个 Pod 优先调度到具有 disk=ssd 标签的节点上，但如果条件不满足，仍然可以调度到其他节点。
步骤
为节点添加标签 ：kubectl label node <node-name> disk=ssd
在 Pod 配置文件中设置软亲和性 ：apiVersion: v1
kind: Pod
metadata:
name: soft-affinity-pod
spec:
affinity:
nodeAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: disk
operator: In
values:
- ssd
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f soft-affinity-pod.yaml
验证调度结果 ：kubectl get pod soft-affinity-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
soft-affinity-pod 1 /1 Running 0 10 s 10.244 .1.2 <node-name >
4. 高级配置 多条件亲和性 示例 apiVersion: v1
kind: Pod
metadata:
name: multi-affinity-pod
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: disk
operator: In
values:
- ssd
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
preference:
matchExpressions:
- key: gpu
operator: In
values:
- "true"
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f multi-affinity-pod.yaml
验证调度结果 ：kubectl get pod multi-affinity-pod -o wide
5. 注意事项
硬亲和性的限制 ：
硬亲和性是一种严格的调度策略，如果条件不满足，Pod 将无法启动。
软亲和性的灵活性 ：
软亲和性是一种灵活的调度策略，即使条件不满足，Pod 仍然可以调度到其他节点。
节点标签的管理 ：
确保节点的标签正确设置，避免调度失败或不符合预期。
资源限制的合理性 ：
在设置节点亲和性时，确保节点的资源足够，避免 Pod 无法启动或资源争用。
Pod 亲和性
1. Pod 亲和性说明 什么是 Pod 亲和性？
Pod 亲和性（Pod Affinity） 是 Kubernetes 中用于控制 Pod 调度到与特定 Pod 在同一节点或不同节点的机制。它允许根据其他 Pod 的标签和条件进行调度，支持 亲和性（Affinity） 和 反亲和性（Anti-Affinity） 两种模式。
Pod 亲和性的类型
Pod 亲和性（PodAffinity） ：
Pod 反亲和性（PodAntiAffinity） ：
调度模式
硬亲和性（Required） ：
软亲和性（Preferred） ：
Pod 优先满足条件，但如果条件不满足，仍然可以调度到其他节点。
2. PodAffinity 硬亲和性实战 场景
一个 Pod 必须调度到与具有 app=web 标签的 Pod 在同一节点上。
步骤
创建目标 Pod ：apiVersion: v1
kind: Pod
metadata:
name: web-pod
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
创建具有硬亲和性的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: affinity-pod
spec:
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f web-pod.yaml
kubectl apply -f affinity-pod.yaml
验证调度结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
web- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
affinity- pod 1 / 1 Running 0 5 s 10.244 .1 .3 node1
3. PodAffinity 软亲和性实战 场景
一个 Pod 优先调度到与具有 app=web 标签的 Pod 在同一节点上，但如果条件不满足，仍然可以调度到其他节点。
步骤
创建目标 Pod ：apiVersion: v1
kind: Pod
metadata:
name: web-pod
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
创建具有软亲和性的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: soft-affinity-pod
spec:
affinity:
podAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f web-pod.yaml
kubectl apply -f soft-affinity-pod.yaml
验证调度结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
web- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
soft- affinity- pod 1 / 1 Running 0 5 s 10.244 .1 .3 node1
4. PodAntiAffinity 硬亲和性实战 场景
一个 Pod 必须调度到与具有 app=web 标签的 Pod 不在同一节点上。
步骤
创建目标 Pod ：apiVersion: v1
kind: Pod
metadata:
name: web-pod
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
创建具有硬反亲和性的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: anti-affinity-pod
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f web-pod.yaml
kubectl apply -f anti-affinity-pod.yaml
验证调度结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
web- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
anti- affinity- pod 1 / 1 Running 0 5 s 10.244 .2 .2 node2
5. PodAntiAffinity 软亲和性实战 场景
一个 Pod 优先调度到与具有 app=web 标签的 Pod 不在同一节点上，但如果条件不满足，仍然可以调度到其他节点。
步骤
创建目标 Pod ：apiVersion: v1
kind: Pod
metadata:
name: web-pod
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
创建具有软反亲和性的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: soft-anti-affinity-pod
spec:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f web-pod.yaml
kubectl apply -f soft-anti-affinity-pod.yaml
验证调度结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
web- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
soft- anti- affinity- pod 1 / 1 Running 0 5 s 10.244 .2 .2 node2
6. 生产案例 场景
一个生产环境中，需要确保同一应用的多个副本分布在不同的节点上，以提高可用性。
解决方案
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- web
topologyKey: kubernetes.io/hostname
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f web-deployment.yaml
验证调度结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
web- deployment-5 f7b5f6c4b-2 q6wz 1 / 1 Running 0 10 s 10.244 .1 .2 node1
web- deployment-5 f7b5f6c4b-4 x8yv 1 / 1 Running 0 10 s 10.244 .2 .2 node2
web- deployment-5 f7b5f6c4b-6 z9xw 1 / 1 Running 0 10 s 10.244 .3 .2 node3
7. 注意事项
调度策略的合理性 ：
根据实际需求选择合适的调度策略，避免过度限制或资源浪费。
节点资源的充足性 ：
确保节点资源足够，避免 Pod 无法启动或资源争用。
标签的管理 ：
确保 Pod 和节点的标签正确设置，避免调度失败或不符合预期。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证调度策略的有效性。
节点和污点管理
1. 节点和污点 什么是节点污点？
节点污点（Taint） 是 Kubernetes 中用于标记节点的机制，表示该节点不接受某些 Pod 的调度。污点由 键（Key） 、值（Value） 和 效果（Effect） 组成，效果包括：
NoSchedule：Pod 不会被调度到该节点。PreferNoSchedule：Pod 尽量避免调度到该节点。NoExecute：Pod 不会被调度到该节点，且已运行的 Pod 会被驱逐。
什么是容忍？
容忍（Toleration） 是 Kubernetes 中用于允许 Pod 调度到具有特定污点的节点的机制。容忍由 键（Key） 、值（Value） 、操作符（Operator） 和 效果（Effect） 组成。
2. 节点污点管理 添加污点
使用 kubectl taint 命令 ：kubectl taint nodes <node-name> key=value:NoSchedule
示例 ：kubectl taint nodes node1 gpu=true :NoSchedule
查看污点 kubectl describe node <node-name>
输出中会显示污点信息：
Taints: gpu=true :NoSchedule
删除污点
使用 kubectl taint 命令 ：kubectl taint nodes <node-name> key=value:NoSchedule-
示例 ：kubectl taint nodes node1 gpu=true :NoSchedule-
3. 污点和容忍应用实战 场景 1：限制 Pod 调度到特定节点
为节点添加污点 ：kubectl taint nodes node1 gpu=true :NoSchedule
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
验证调度结果 ：kubectl get pod my-pod -o wide
node1：NAME READY STATUS RESTARTS AGE IP NODE
my -pod 1 /1 Running 0 10 s 10.244 .2.2 node2
场景 2：允许 Pod 调度到具有特定污点的节点
为节点添加污点 ：kubectl taint nodes node1 gpu=true :NoSchedule
创建具有容忍的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: tolerant-pod
spec:
containers:
- name: nginx
image: nginx
tolerations:
- key: "gpu"
operator: "Equal"
value: "true"
effect: "NoSchedule"
验证调度结果 ：kubectl get pod tolerant-pod -o wide
node1：NAME READY STATUS RESTARTS AGE IP NODE
tolerant- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
场景 3：驱逐已运行的 Pod
为节点添加污点 ：kubectl taint nodes node1 gpu=true :NoExecute
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
验证调度结果 ：kubectl get pod my-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my-pod 0 /1 Evicted 0 10s <none > <none >
创建具有容忍的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: tolerant-pod
spec:
containers:
- name: nginx
image: nginx
tolerations:
- key: "gpu"
operator: "Equal"
value: "true"
effect: "NoExecute"
验证调度结果 ：kubectl get pod tolerant-pod -o wide
node1：NAME READY STATUS RESTARTS AGE IP NODE
tolerant- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
4. 生产案例 场景
一个生产环境中，需要确保某些节点只运行特定的 Pod（如 GPU 任务），而其他 Pod 不会调度到这些节点。
解决方案
为 GPU 节点添加污点 ：kubectl taint nodes gpu-node1 gpu=true :NoSchedule
kubectl taint nodes gpu-node2 gpu=true :NoSchedule
创建 GPU 任务的 Pod ：apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
spec:
containers:
- name: nvidia
image: nvidia/cuda:11.0-base
tolerations:
- key: "gpu"
operator: "Equal"
value: "true"
effect: "NoSchedule"
验证调度结果 ：kubectl get pod gpu-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
gpu- pod 1 / 1 Running 0 10 s 10.244 .1 .2 gpu- node1
5. 注意事项
污点的合理性 ：
根据实际需求合理设置污点，避免过度限制或资源浪费。
容忍的管理 ：
确保 Pod 的容忍与节点的污点匹配，避免调度失败或不符合预期。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证污点和容忍的有效性。
节点资源的充足性 ：
确保节点资源足够，避免 Pod 无法启动或资源争用。
Pod的重启策略、生命周期、探针
1. 常见的 Pod 状态 Pod 的状态
Pending ：
Pod 已被 Kubernetes 接受，但尚未调度到节点上。
可能原因：调度器正在寻找合适的节点，或镜像正在下载。
Running ：
Pod 已调度到节点上，且所有容器已启动。
可能原因：Pod 正常运行。
Succeeded ：
Pod 中的所有容器已成功完成并退出。
可能原因：任务型 Pod 已完成。
Failed ：
Pod 中的至少一个容器已失败并退出。
可能原因：容器启动失败或任务执行失败。
Unknown ：
Pod 的状态无法确定。
可能原因：节点与 API Server 通信失败。
CrashLoopBackOff ：
Pod 中的容器反复崩溃并重启。
可能原因：容器启动失败或配置错误。
Terminating ：
Pod 正在被删除。
可能原因：用户手动删除 Pod 或资源回收。
2. 重启策略 什么是重启策略？
重启策略（Restart Policy） 是 Kubernetes 中用于控制 Pod 中容器重启行为的机制。重启策略包括：
Always：容器退出时总是重启（默认策略）。OnFailure：容器非正常退出时重启。Never：容器退出时不重启。
设置重启策略
在 Pod 配置文件中设置 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: OnFailure
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f pod.yaml
验证重启策略 ：kubectl describe pod my-pod
Restart Policy: OnFailure
3. Pod 的生命周期 Pod 的生命周期阶段
Pending ：
Pod 已被 Kubernetes 接受，但尚未调度到节点上。
Running ：
Succeeded/Failed ：
Terminating ：
Pod 的生命周期事件
初始化容器（Init Containers） ：
应用容器（Containers） ：
钩子（Hooks） ：
启动后钩子（PostStart） ：容器启动后执行的操作。停止前钩子（PreStop） ：容器停止前执行的操作。
探针（Probes） ：
存活探针（Liveness Probe） ：检查容器是否存活。就绪探针（Readiness Probe） ：检查容器是否就绪。启动探针（Startup Probe） ：检查容器是否启动完成。
Pod 的生命周期示例
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: lifecycle-pod
spec:
containers:
- name: nginx
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh" , "-c" , "echo 'Container started' > /tmp/start.log" ]
preStop:
exec:
command: ["/bin/sh" , "-c" , "echo 'Container stopping' > /tmp/stop.log" ]
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
应用配置文件 ：kubectl apply -f lifecycle-pod.yaml
验证生命周期事件 ：kubectl exec lifecycle-pod -- cat /tmp/start.log
kubectl exec lifecycle-pod -- cat /tmp/stop.log
Container started
Container stopping
4. 生产案例 场景
一个生产环境中，需要确保应用容器在启动前完成初始化任务，并在停止前执行清理操作。
解决方案
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: production-pod
spec:
initContainers:
- name: init
image: busybox
command: ["/bin/sh" , "-c" , "echo 'Initialization complete' > /tmp/init.log" ]
containers:
- name: nginx
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh" , "-c" , "echo 'Container started' > /tmp/start.log" ]
preStop:
exec:
command: ["/bin/sh" , "-c" , "echo 'Container stopping' > /tmp/stop.log" ]
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
应用配置文件 ：kubectl apply -f production-pod.yaml
验证生命周期事件 ：kubectl exec production-pod -- cat /tmp/init.log
kubectl exec production-pod -- cat /tmp/start.log
kubectl exec production-pod -- cat /tmp/stop.log
Initialization complete
Container started
Container stopping
5. 注意事项
重启策略的合理性 ：
根据实际需求合理设置重启策略，避免过度重启或资源浪费。
生命周期事件的管理 ：
确保生命周期事件的命令正确执行，避免影响 Pod 的正常运行。
探针的配置 ：
合理配置探针，确保容器在启动、运行和停止时都能正确响应。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证生命周期事件和探针的有效性。
容器钩子与探针
1. 容器钩子实战 什么是容器钩子？
容器钩子（Container Hooks） 是 Kubernetes 中用于在容器生命周期中执行特定操作的机制。包括 启动后钩子（PostStart） 和 停止前钩子（PreStop） 。
启动后钩子（PostStart） 停止前钩子（PreStop） 实战案例
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: hook-pod
spec:
containers:
- name: nginx
image: nginx
lifecycle:
postStart:
exec:
command: ["/bin/sh" , "-c" , "echo 'Container started' > /tmp/start.log" ]
preStop:
exec:
command: ["/bin/sh" , "-c" , "echo 'Container stopping' > /tmp/stop.log" ]
应用配置文件 ：kubectl apply -f hook-pod.yaml
验证钩子事件 ：kubectl exec hook-pod -- cat /tmp/start.log
kubectl exec hook-pod -- cat /tmp/stop.log
Container started
Container stopping
2. StartupProbe 启动探测应用案例 什么是 StartupProbe？
StartupProbe 是 Kubernetes 中用于检测容器是否启动完成的机制。它允许在容器启动期间延迟其他探针（如 LivenessProbe 和 ReadinessProbe）的执行。
应用案例
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: startup-pod
spec:
containers:
- name: nginx
image: nginx
startupProbe:
httpGet:
path: /
port: 80
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
应用配置文件 ：kubectl apply -f startup-pod.yaml
验证 StartupProbe ：kubectl describe pod startup-pod
Startup Probe: http-get http://:80/ delay=0s timeout =1s period=10s
3. 三种探针的启动顺序问题 三种探针
StartupProbe ：
用于检测容器是否启动完成。
在容器启动期间延迟其他探针的执行。
LivenessProbe ：
用于检测容器是否存活。
如果检测失败，Kubernetes 会重启容器。
ReadinessProbe ：
用于检测容器是否就绪。
如果检测失败，Kubernetes 会将容器从 Service 的负载均衡中移除。
启动顺序
StartupProbe 优先 ：
在容器启动期间，StartupProbe 优先执行，直到检测成功或失败。
LivenessProbe 和 ReadinessProbe 延迟 ：
在 StartupProbe 检测成功之前，LivenessProbe 和 ReadinessProbe 不会执行。
StartupProbe 检测成功后 ：
LivenessProbe 和 ReadinessProbe 开始执行，按照各自的配置进行检测。
示例
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: probe-pod
spec:
containers:
- name: nginx
image: nginx
startupProbe:
httpGet:
path: /
port: 80
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
应用配置文件 ：kubectl apply -f probe-pod.yaml
验证探针启动顺序 ：kubectl describe pod probe-pod
Startup Probe: http-get http://:80/ delay=0s timeout =1s period=10s
Liveness Probe: http-get http://:80/ delay=5s timeout =1s period=10s
Readiness Probe: http-get http://:80/ delay=5s timeout =1s period=10s
4. 生产案例 场景
一个生产环境中，需要确保应用容器在启动完成后再进行存活和就绪检测，以避免误判。
解决方案
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: production-pod
spec:
containers:
- name: nginx
image: nginx
startupProbe:
httpGet:
path: /
port: 80
failureThreshold: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
readinessProbe:
httpGet:
path: /
port: 80
initialDelaySeconds: 5
periodSeconds: 10
应用配置文件 ：kubectl apply -f production-pod.yaml
验证探针启动顺序 ：kubectl describe pod production-pod
Startup Probe: http-get http://:80/ delay=0s timeout =1s period=10s
Liveness Probe: http-get http://:80/ delay=5s timeout =1s period=10s
Readiness Probe: http-get http://:80/ delay=5s timeout =1s period=10s
5. 注意事项
StartupProbe 的配置 ：
合理配置 StartupProbe 的 failureThreshold 和 periodSeconds，确保容器有足够的时间启动。
探针的启动顺序 ：
确保 StartupProbe 优先执行，避免 LivenessProbe 和 ReadinessProbe 在容器启动期间误判。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证探针的配置和启动顺序的有效性。
钩子的执行时间 ：
确保钩子的命令在合理的时间内执行完成，避免影响容器的正常启动和停止。
Pod 优先级和抢占式调度
1. 什么是 Pod 优先级和抢占式调度？ Pod 优先级
Pod 优先级（Pod Priority） 是 Kubernetes 中用于定义 Pod 调度优先级的一种机制。优先级高的 Pod 在资源不足时会被优先调度，而优先级低的 Pod 可能会被延迟调度或抢占。
优先级通过 PriorityClass 资源定义，每个 PriorityClass 有一个整数值，值越大优先级越高。
抢占式调度
抢占式调度（Preemption） 是 Kubernetes 中用于在资源不足时，通过驱逐低优先级 Pod 来调度高优先级 Pod 的一种机制。当高优先级 Pod 无法调度时，Kubernetes 会尝试驱逐低优先级 Pod 以释放资源。
抢占式调度可能会导致低优先级 Pod 被终止或重新调度。
2. Pod 优先级和抢占式调度实战 步骤 1：创建 PriorityClass
创建高优先级 PriorityClass ：apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority pods."
创建低优先级 PriorityClass ：apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: low-priority
value: 1000
globalDefault: false
description: "This priority class should be used for low priority pods."
应用配置文件 ：kubectl apply -f high-priority.yaml
kubectl apply -f low-priority.yaml
步骤 2：创建低优先级 Pod
创建低优先级 Pod ：apiVersion: v1
kind: Pod
metadata:
name: low-priority-pod
spec:
containers:
- name: nginx
image: nginx
priorityClassName: low-priority
应用配置文件 ：kubectl apply -f low-priority-pod.yaml
验证 Pod 状态 ：kubectl get pod low-priority-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
low- priority- pod 1 / 1 Running 0 10 s 10.244 .1 .2 node1
步骤 3：创建高优先级 Pod
创建高优先级 Pod ：apiVersion: v1
kind: Pod
metadata:
name: high-priority-pod
spec:
containers:
- name: nginx
image: nginx
priorityClassName: high-priority
应用配置文件 ：kubectl apply -f high-priority-pod.yaml
验证 Pod 状态 ：kubectl get pod high-priority-pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE
high- priority- pod 1 / 1 Running 0 10 s 10.244 .1 .3 node1
low- priority- pod 0 / 1 Evicted 0 1 m < none > < none >
步骤 4：查看抢占事件
查看事件日志 ：kubectl get events
LAST SEEN TYPE REASON OBJECT MESSAGE
10 s Normal Preempted pod/low-priority-pod Preempted by pod/high-priority-pod
3. 生产案例 场景
一个生产环境中，需要确保关键任务 Pod 在资源不足时优先调度，而非关键任务 Pod 可以被抢占。
解决方案
创建 PriorityClass ：apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
name: critical-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for critical pods."
创建非关键任务 Pod ：apiVersion: v1
kind: Pod
metadata:
name: non-critical-pod
spec:
containers:
- name: nginx
image: nginx
priorityClassName: low-priority
创建关键任务 Pod ：apiVersion: v1
kind: Pod
metadata:
name: critical-pod
spec:
containers:
- name: nginx
image: nginx
priorityClassName: critical-priority
应用配置文件 ：kubectl apply -f critical-priority.yaml
kubectl apply -f non-critical-pod.yaml
kubectl apply -f critical-pod.yaml
验证调度结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
critical- pod 1 / 1 Running 0 10 s 10.244 .1 .3 node1
non- critical- pod 0 / 1 Evicted 0 1 m < none > < none >
4. 注意事项
优先级的合理性 ：
根据实际需求合理设置优先级，避免过度抢占或资源浪费。
抢占的影响 ：
抢占式调度可能会导致低优先级 Pod 被终止或重新调度，需评估其对业务的影响。
资源配额的管理 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证优先级和抢占式调度的有效性。
ReplicaSet 控制器
1. ReplicaSet 控制器的概念与原理 什么是 ReplicaSet？
ReplicaSet 是 Kubernetes 中用于确保指定数量的 Pod 副本始终运行的控制器。它通过监控 Pod 的状态，自动创建或删除 Pod 以满足期望的副本数。
ReplicaSet 的工作原理
定义期望状态 ：
用户通过 YAML 文件定义 ReplicaSet 的期望状态，包括 Pod 模板和副本数。
监控当前状态 ：
ReplicaSet 监控集群中与 Pod 模板匹配的 Pod 数量。
调整实际状态 ：
如果当前 Pod 数量少于期望值，ReplicaSet 会创建新的 Pod。
如果当前 Pod 数量多于期望值，ReplicaSet 会删除多余的 Pod。
标签选择器 ：
ReplicaSet 通过标签选择器（Label Selector）识别和管理 Pod。
2. 创建多副本 Pod 步骤
创建 ReplicaSet 配置文件 ：apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f replicaset.yaml
验证 ReplicaSet 和 Pod ：kubectl get replicaset
kubectl get pods
NAME DESIRED CURRENT READY AGE
my -replicaset 3 3 3 10 s
NAME READY STATUS RESTARTS AGE
my -replicaset-abcde 1 /1 Running 0 10 s
my -replicaset-fghij 1 /1 Running 0 10 s
my -replicaset-klmno 1 /1 Running 0 10 s
3. 实现 Pod 动态扩容 步骤
修改 ReplicaSet 的副本数 ：kubectl scale replicaset my-replicaset --replicas=5
验证扩容结果 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
my -replicaset-abcde 1 /1 Running 0 10 s
my -replicaset-fghij 1 /1 Running 0 10 s
my -replicaset-klmno 1 /1 Running 0 10 s
my -replicaset-pqrst 1 /1 Running 0 5 s
my -replicaset-uvwxy 1 /1 Running 0 5 s
4. 实现 Pod 动态缩容 步骤
修改 ReplicaSet 的副本数 ：kubectl scale replicaset my-replicaset --replicas=2
验证缩容结果 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
my -replicaset-abcde 1 /1 Running 0 10 s
my -replicaset-fghij 1 /1 Running 0 10 s
5. 实现 Pod 动态更新 场景
更新 Pod 的镜像版本，并确保 ReplicaSet 逐步替换旧 Pod。
步骤
修改 ReplicaSet 的镜像版本 ：apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
应用配置文件 ：kubectl apply -f replicaset.yaml
验证更新结果 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
my -replicaset-abcde 1 /1 Running 0 10 s 10.244 .1.2 node1
my -replicaset-fghij 1 /1 Running 0 10 s 10.244 .1.3 node1
my -replicaset-klmno 1 /1 Running 0 10 s 10.244 .1.4 node1
my -replicaset-pqrst 1 /1 Running 0 5 s 10.244 .2.2 node2
my -replicaset-uvwxy 1 /1 Running 0 5 s 10.244 .2.3 node2
6. 生产案例 场景
一个生产环境中，需要确保应用的高可用性，并根据负载动态调整 Pod 数量。
解决方案
创建 ReplicaSet ：apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: production-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: production
template:
metadata:
labels:
app: production
spec:
containers:
- name: nginx
image: nginx
动态扩容 ：kubectl scale replicaset production-replicaset --replicas=5
动态缩容 ：kubectl scale replicaset production-replicaset --replicas=2
动态更新 ：apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: production-replicaset
spec:
replicas: 3
selector:
matchLabels:
app: production
template:
metadata:
labels:
app: production
spec:
containers:
- name: nginx
image: nginx:1.21
应用配置文件 ：kubectl apply -f production-replicaset.yaml
验证结果 ：kubectl get pods -o wide
7. 注意事项
ReplicaSet 与 Deployment 的区别 ：
ReplicaSet 仅用于管理 Pod 副本，而 Deployment 提供了更高级的功能（如滚动更新）。
标签选择器的唯一性 ：
确保 ReplicaSet 的标签选择器唯一，避免管理错误的 Pod。
资源配额的管理 ：
动态扩容时，确保集群资源足够，避免 Pod 无法调度。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 ReplicaSet 的配置和操作。
Deployment 控制器
1. Deployment 控制器 什么是 Deployment？
Deployment 是 Kubernetes 中用于管理 Pod 和 ReplicaSet 的高级控制器。它提供了声明式更新、滚动升级、回滚等功能，确保应用的高可用性和可扩展性。
Deployment 的工作原理
定义期望状态 ：
用户通过 YAML 文件定义 Deployment 的期望状态，包括 Pod 模板、副本数和更新策略。
创建 ReplicaSet ：
Deployment 创建 ReplicaSet 来管理 Pod 副本。
监控和调整 ：
Deployment 监控 ReplicaSet 和 Pod 的状态，确保实际状态与期望状态一致。
滚动更新 ：
当 Pod 模板或副本数发生变化时，Deployment 会逐步替换旧的 Pod，确保应用不中断。
回滚 ：
如果更新失败，Deployment 可以回滚到之前的版本。
创建 Deployment
创建 Deployment 配置文件 ：apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f deployment.yaml
验证 Deployment 和 Pod ：kubectl get deployment
kubectl get pods
NAME READY UP-TO-DATE AVAILABLE AGE
my -deployment 3 /3 3 3 10 s
NAME READY STATUS RESTARTS AGE
my -deployment-5 f7b5f6c4b-abcde 1 /1 Running 0 10 s
my -deployment-5 f7b5f6c4b-fghij 1 /1 Running 0 10 s
my -deployment-5 f7b5f6c4b-klmno 1 /1 Running 0 10 s
2. Pod 中添加域名解析 什么是域名解析？
域名解析 是将域名转换为 IP 地址的过程。在 Kubernetes 中，Pod 可以通过 DNS 解析其他服务的域名。
添加域名解析
创建 Service ：apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
应用配置文件 ：kubectl apply -f service.yaml
在 Pod 中解析域名 ：kubectl exec -it my-pod -- nslookup my-service
Server: 10.96 .0 .10
Address 1: 10.96 .0 .10 kube-dns.kube-system.svc.cluster.local
Name: my-service
Address 1: 10.96 .1 .2 my-service.default.svc.cluster.local
3. Pod 中 DNS 配置 什么是 DNS 配置？
DNS 配置 是 Kubernetes 中用于定义 Pod 的 DNS 解析行为的机制。通过 dnsConfig 和 dnsPolicy 字段，可以自定义 Pod 的 DNS 设置。
DNS 配置字段
dnsPolicy ：
ClusterFirst：优先使用集群的 DNS 服务（默认值）。Default：使用节点的 DNS 配置。None：不设置 DNS，需手动配置 dnsConfig。
dnsConfig ：
nameservers：自定义 DNS 服务器列表。searches：自定义 DNS 搜索域列表。options：自定义 DNS 选项。
配置示例
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: dns-pod
spec:
containers:
- name: nginx
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 8.8 .8 .8
searches:
- mydomain.com
options:
- name: ndots
value: "2"
应用配置文件 ：kubectl apply -f dns-pod.yaml
验证 DNS 配置 ：kubectl exec -it dns-pod -- cat /etc/resolv.conf
nameserver 8.8 .8 .8
search mydomain.com
options ndots:2
4. 生产案例 场景
一个生产环境中，需要确保应用的高可用性，并通过自定义 DNS 配置解析外部域名。
解决方案
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: production-deployment
spec:
replicas: 3
selector:
matchLabels:
app: production
template:
metadata:
labels:
app: production
spec:
containers:
- name: nginx
image: nginx
dnsPolicy: "None"
dnsConfig:
nameservers:
- 8.8 .8 .8
searches:
- production.mydomain.com
options:
- name: ndots
value: "2"
应用配置文件 ：kubectl apply -f production-deployment.yaml
验证 DNS 配置 ：kubectl exec -it production-deployment-abcde -- cat /etc/resolv.conf
nameserver 8.8 .8 .8
search production.mydomain.com
options ndots:2
5. 注意事项
Deployment 的更新策略 ：
合理设置更新策略（如 RollingUpdate），确保应用不中断。
DNS 配置的合理性 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Deployment 和 DNS 配置的有效性。
资源配额的管理 ：
Deployment控制器实战
1. 创建 Web 站点 步骤
创建 Deployment 配置文件 ：apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
应用配置文件 ：kubectl apply -f web-deployment.yaml
验证 Deployment 和 Pod ：kubectl get deployment
kubectl get pods
NAME READY UP- TO - DATE AVAILABLE AGE
web- deployment 3 / 3 3 3 10 s
NAME READY STATUS RESTARTS AGE
web- deployment-5 f7b5f6c4b- abcde 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- fghij 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- klmno 1 / 1 Running 0 10 s
2. 实现 Pod 动态扩容 步骤
修改 Deployment 的副本数 ：kubectl scale deployment web-deployment --replicas=5
验证扩容结果 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
web- deployment-5 f7b5f6c4b- abcde 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- fghij 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- klmno 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- pqrst 1 / 1 Running 0 5 s
web- deployment-5 f7b5f6c4b- uvwxy 1 / 1 Running 0 5 s
3. 实现 Pod 动态缩容 步骤
修改 Deployment 的副本数 ：kubectl scale deployment web-deployment --replicas=2
验证缩容结果 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
web- deployment-5 f7b5f6c4b- abcde 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- fghij 1 / 1 Running 0 10 s
4. 实现 Pod 滚动升级 步骤
更新 Deployment 的镜像版本 ：kubectl set image deployment/web-deployment nginx=nginx:1.22
验证滚动升级 ：kubectl rollout status deployment/web-deployment
deployment "web-deployment" successfully rolled out
查看 Pod 状态 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
web- deployment-6 d5b8c5d8b- abcde 1 / 1 Running 0 10 s
web- deployment-6 d5b8c5d8b- fghij 1 / 1 Running 0 10 s
web- deployment-6 d5b8c5d8b- klmno 1 / 1 Running 0 10 s
5. 实现 Pod 版本回退 步骤
查看 Deployment 的历史版本 ：kubectl rollout history deployment/web-deployment
REVISION CHANGE-CAUSE
1 <none >
2 <none >
回退到指定版本 ：kubectl rollout undo deployment/web-deployment --to-revision=1
验证回退结果 ：kubectl rollout status deployment/web-deployment
kubectl get pods
NAME READY STATUS RESTARTS AGE
web- deployment-5 f7b5f6c4b- abcde 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- fghij 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- klmno 1 / 1 Running 0 10 s
6. 自定义滚动更新策略 步骤
修改 Deployment 的更新策略 ：apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
应用配置文件 ：kubectl apply -f web-deployment.yaml
验证更新策略 ：kubectl describe deployment web-deployment
StrategyType: RollingUpdate
RollingUpdateStrategy: 1 max unavailable, 1 max surge
7. 生产案例 场景
一个生产环境中，需要确保 Web 站点的高可用性，并根据负载动态调整 Pod 数量，同时支持滚动升级和版本回退。
解决方案
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: production-deployment
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
selector:
matchLabels:
app: production
template:
metadata:
labels:
app: production
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
动态扩容 ：kubectl scale deployment production-deployment --replicas=5
动态缩容 ：kubectl scale deployment production-deployment --replicas=2
滚动升级 ：kubectl set image deployment/production-deployment nginx=nginx:1.22
版本回退 ：kubectl rollout undo deployment/production-deployment --to-revision=1
8. 注意事项
更新策略的合理性 ：
根据实际需求合理设置 maxSurge 和 maxUnavailable，确保应用不中断。
资源配额的管理 ：
动态扩容时，确保集群资源足够，避免 Pod 无法调度。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Deployment 的配置和操作。
版本回退的可行性 ：
DaemonSet 控制器
1. DaemonSet 控制器 什么是 DaemonSet？
DaemonSet 是 Kubernetes 中用于确保每个节点（或满足条件的节点）上都运行一个 Pod 副本的控制器。它通常用于部署系统级别的守护进程，如日志收集、网络插件、监控代理等。
DaemonSet 的工作原理
定义期望状态 ：
用户通过 YAML 文件定义 DaemonSet 的期望状态，包括 Pod 模板和节点选择器。
监控节点状态 ：
DaemonSet 监控集群中的节点，确保每个节点上都运行一个 Pod 副本。
调整实际状态 ：
如果节点数量增加，DaemonSet 会自动创建新的 Pod。
如果节点数量减少，DaemonSet 会自动删除多余的 Pod。
节点选择器 ：
通过 nodeSelector 或 affinity 字段，可以限制 DaemonSet 在特定节点上运行。
2. 使用 DaemonSet 部署日志收集组件 Fluentd 场景
在 Kubernetes 集群中，每个节点上都需要运行一个 Fluentd Pod，用于收集节点和容器的日志。
步骤
创建 DaemonSet 配置文件 ：apiVersion: apps/v1
kind: DaemonSet
metadata:
name: fluentd
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd
template:
metadata:
labels:
name: fluentd
spec:
containers:
- name: fluentd
image: fluent/fluentd:latest
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
应用配置文件 ：kubectl apply -f fluentd-daemonset.yaml
验证 DaemonSet 和 Pod ：kubectl get daemonset
kubectl get pods -o wide
NAME DESIRED CURRENT READY UP- TO - DATE AVAILABLE NODE SELECTOR AGE
fluentd 3 3 3 3 3 < none > 10 s
NAME READY STATUS RESTARTS AGE IP NODE
fluentd- abcde 1 / 1 Running 0 10 s 10.244 .1 .2 node1
fluentd- fghij 1 / 1 Running 0 10 s 10.244 .2 .2 node2
fluentd- klmno 1 / 1 Running 0 10 s 10.244 .3 .2 node3
3. DaemonSet 滚动更新 Pod 场景
更新 Fluentd 的镜像版本，并确保 DaemonSet 逐步替换旧 Pod。
步骤
更新 DaemonSet 的镜像版本 ：kubectl set image daemonset/fluentd fluentd=fluent/fluentd:v1.14
验证滚动更新 ：kubectl rollout status daemonset/fluentd
daemon set "fluentd" successfully rolled out
查看 Pod 状态 ：kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
fluentd- pqrst 1 / 1 Running 0 10 s 10.244 .1 .3 node1
fluentd- uvwxy 1 / 1 Running 0 10 s 10.244 .2 .3 node2
fluentd- zabcd 1 / 1 Running 0 10 s 10.244 .3 .3 node3
4. 生产案例 场景
一个生产环境中，需要在每个节点上部署 Fluentd 用于日志收集，并支持滚动更新。
解决方案
创建 DaemonSet ：apiVersion: apps/v1
kind: DaemonSet
metadata:
name: production-fluentd
labels:
k8s-app: fluentd-logging
spec:
selector:
matchLabels:
name: fluentd
template:
metadata:
labels:
name: fluentd
spec:
containers:
- name: fluentd
image: fluent/fluentd:latest
volumeMounts:
- name: varlog
mountPath: /var/log
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
volumes:
- name: varlog
hostPath:
path: /var/log
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
应用配置文件 ：kubectl apply -f production-fluentd.yaml
滚动更新 ：kubectl set image daemonset/production-fluentd fluentd=fluent/fluentd:v1.14
验证更新结果 ：kubectl rollout status daemonset/production-fluentd
kubectl get pods -o wide
5. 注意事项
节点选择器的使用 ：
通过 nodeSelector 或 affinity 字段，可以限制 DaemonSet 在特定节点上运行。
资源配额的管理 ：
滚动更新的策略 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 DaemonSet 的配置和操作。
四层负载均衡 Service
1. 四层负载均衡 Service 什么是 Service？
Service 是 Kubernetes 中用于为一组 Pod 提供稳定的网络访问的抽象。它通过负载均衡将流量分发到后端的 Pod，并提供以下功能：
服务发现：通过 DNS 或环境变量暴露服务。
负载均衡：将流量均匀分发到多个 Pod。
网络隔离：通过 ClusterIP 或 NodePort 控制访问范围。
Service 的类型
ClusterIP ：
NodePort ：
在 ClusterIP 的基础上，通过节点的 IP 和端口暴露服务。
LoadBalancer ：
在 NodePort 的基础上，通过云提供商的负载均衡器暴露服务。
ExternalName ：
无标签选择器的 Service ：
2. 类型为 ClusterIP 实战 场景
在集群内部暴露一个 Web 服务，供其他 Pod 访问。
步骤
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: web-deployment
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
创建 ClusterIP Service ：apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: ClusterIP
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 80
应用配置文件 ：kubectl apply -f web-deployment.yaml
kubectl apply -f web-service.yaml
验证 Service 和 Pod ：kubectl get service
kubectl get pods
NAME TYPE CLUSTER- IP EXTERNAL - IP PORT(S) AGE
web- service ClusterIP 10.96 .1 .2 < none > 80 / TCP 10 s
NAME READY STATUS RESTARTS AGE
web- deployment-5 f7b5f6c4b- abcde 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- fghij 1 / 1 Running 0 10 s
web- deployment-5 f7b5f6c4b- klmno 1 / 1 Running 0 10 s
在集群内部访问 Service ：kubectl run curl --image=curlimages/curl --rm -it --restart=Never -- curl http://web-service
3. 类型为 NodePort 实战 场景
通过节点的 IP 和端口暴露 Web 服务，供外部访问。
步骤
创建 NodePort Service ：apiVersion: v1
kind: Service
metadata:
name: web-service
spec:
type: NodePort
selector:
app: web
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
应用配置文件 ：kubectl apply -f web-service.yaml
验证 Service ：kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGE
web-service NodePort 10.96 .1 .2 <none > 80 :30080 /TCP 10s
通过节点 IP 访问服务 ：
使用节点的 IP 和端口（如 http://<NodeIP>:30080）访问服务。
4. 类型为 ExternalName 实战 场景 步骤
创建 ExternalName Service ：apiVersion: v1
kind: Service
metadata:
name: external-service
spec:
type: ExternalName
externalName: example.com
应用配置文件 ：kubectl apply -f external-service.yaml
验证 Service ：kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT (S) AGE
external-service ExternalName <none > example.com <none > 10s
在集群内部访问 Service ：kubectl run curl --image=curlimages/curl --rm -it --restart=Never -- curl http://external-service
example.com 的内容。
5. 无标签选择器的 Service（关联外部服务实战） 场景
将 Service 关联到外部服务（如数据库），供集群内部访问。
步骤
创建无标签选择器的 Service ：apiVersion: v1
kind: Service
metadata:
name: external-db-service
spec:
ports:
- protocol: TCP
port: 3306
targetPort: 3306
创建 Endpoints ：apiVersion: v1
kind: Endpoints
metadata:
name: external-db-service
subsets:
- addresses:
- ip: 192.168 .1 .100
ports:
- port: 3306
应用配置文件 ：kubectl apply -f external-db-service.yaml
kubectl apply -f endpoints.yaml
验证 Service 和 Endpoints ：kubectl get service
kubectl get endpoints
NAME TYPE CLUSTER-IP EXTERNAL -IP PORT(S) AGE
external -db-service ClusterIP 10.96 .1.3 <none> 3306 /TCP 10 s
NAME ENDPOINTS AGE
external -db-service 192.168 .1.100 :3306 10 s
在集群内部访问 Service ：kubectl run mysql-client --image=mysql:5.7 --rm -it --restart=Never -- mysql -h external-db-service -u root -p
6. 生产案例 场景
一个生产环境中，需要为 Web 服务提供稳定的内部访问，并通过 NodePort 暴露给外部用户。
解决方案
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: production-web
spec:
replicas: 3
selector:
matchLabels:
app: production-web
template:
metadata:
labels:
app: production-web
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80
创建 NodePort Service ：apiVersion: v1
kind: Service
metadata:
name: production-web-service
spec:
type: NodePort
selector:
app: production-web
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
应用配置文件 ：kubectl apply -f production-web.yaml
kubectl apply -f production-web-service.yaml
验证 Service 和 Pod ：kubectl get service
kubectl get pods
7. 注意事项
Service 的类型选择 ：
根据实际需求选择合适的 Service 类型（如 ClusterIP、NodePort、ExternalName）。
资源配额的管理 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Service 的配置和操作。
安全策略 ：
通过 NetworkPolicy 或 RBAC 控制 Service 的访问权限。
持久化存储
1. 在 Kubernetes 中为什么要做持久化存储？ 背景
Kubernetes 中的 Pod 是临时的，可能会被删除、重新调度或重启。
默认情况下，Pod 中的数据存储在容器的文件系统中，当 Pod 被删除时，数据也会丢失。
持久化存储的必要性
数据持久化 ：
数据共享 ：
数据备份与恢复 ：
应用场景 ：
2. 持久化存储 emptyDir 什么是 emptyDir？
emptyDir 是一种临时存储卷，生命周期与 Pod 绑定。当 Pod 被删除时，emptyDir 中的数据也会被删除。
使用场景 实战示例
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: emptydir-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: cache-volume
mountPath: /cache
volumes:
- name: cache-volume
emptyDir: {}
应用配置文件 ：kubectl apply -f emptydir-pod.yaml
验证 emptyDir ：kubectl exec -it emptydir-pod -- ls /cache
3. 持久化存储 hostPath 什么是 hostPath？
hostPath 是一种将主机文件系统中的目录挂载到 Pod 中的存储卷。数据存储在节点上，Pod 删除后数据仍然存在，但 Pod 重新调度到其他节点时无法访问数据。
使用场景 实战示例
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: hostpath-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: hostpath-volume
mountPath: /host-data
volumes:
- name: hostpath-volume
hostPath:
path: /data
type: Directory
应用配置文件 ：kubectl apply -f hostpath-pod.yaml
验证 hostPath ：kubectl exec -it hostpath-pod -- ls /host-data
4. 持久化存储 NFS 什么是 NFS？
NFS（Network File System） 是一种网络文件系统，允许多个节点共享同一份数据。数据存储在 NFS 服务器上，Pod 删除或重新调度后仍然可以访问数据。
使用场景 实战示例
创建 NFS 服务器 （假设 NFS 服务器已部署，IP 为 192.168.1.100，共享目录为 /data/nfs）。创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: nfs-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: nfs-volume
mountPath: /nfs-data
volumes:
- name: nfs-volume
nfs:
server: 192.168 .1 .100
path: /data/nfs
应用配置文件 ：kubectl apply -f nfs-pod.yaml
验证 NFS ：kubectl exec -it nfs-pod -- ls /nfs-data
5. 生产案例 场景
一个生产环境中，需要为数据库提供持久化存储，并确保数据在 Pod 删除或重新调度后仍然可用。
解决方案
创建 NFS 服务器 （假设 NFS 服务器已部署，IP 为 192.168.1.100，共享目录为 /data/mysql）。创建 Deployment 配置文件 ：apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
spec:
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
volumes:
- name: mysql-data
nfs:
server: 192.168 .1 .100
path: /data/mysql
应用配置文件 ：kubectl apply -f mysql-deployment.yaml
验证持久化存储 ：kubectl exec -it mysql-deployment-abcde -- ls /var/lib/mysql
6. 注意事项
存储类型的选择 ：
根据实际需求选择合适的存储类型（如 emptyDir、hostPath、NFS）。
数据安全 ：
性能优化 ：
根据应用场景优化存储性能，如使用 SSD、调整 NFS 配置等。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证持久化存储的配置和操作。
PV（PersistentVolume）与 PVC（PersistentVolumeClaim）
1. PV 与 PVC 的概念 什么是 PV？
PV（PersistentVolume） 是 Kubernetes 中由管理员提供的存储资源。它可以是本地存储、NFS、云存储等，独立于 Pod 的生命周期。
什么是 PVC？
PVC（PersistentVolumeClaim） 是用户对存储资源的请求。用户通过 PVC 申请存储资源，Kubernetes 会根据 PVC 的要求绑定合适的 PV。
PV 和 PVC 的关系
PV 是集群中的存储资源，PVC 是用户对存储资源的需求。
Kubernetes 通过绑定机制将 PVC 与 PV 关联起来。
2. PV 和 PVC 语法说明与资源创建 PV 的 YAML 语法 apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
nfs:
server: 192.168 .1 .100
path: /data/nfs
PVC 的 YAML 语法 apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
创建 PV 和 PVC
创建 PV ：kubectl apply -f pv.yaml
创建 PVC ：kubectl apply -f pvc.yaml
验证 PV 和 PVC ：kubectl get pv
kubectl get pvc
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
my-pv 10 Gi RWO Retain Bound default /my-pvc 10 s
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
my-pvc Bound my-pv 10 Gi RWO 10 s
3. 挂载 PVC 资源给 Pod 使用 步骤
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: my-storage
mountPath: /mnt/data
volumes:
- name: my-storage
persistentVolumeClaim:
claimName: my-pvc
应用配置文件 ：kubectl apply -f pod.yaml
验证 PVC 挂载 ：kubectl exec -it my-pod -- ls /mnt/data
4. PV 与 PVC 实战应用 场景
一个生产环境中，需要为数据库提供持久化存储，并确保数据在 Pod 删除或重新调度后仍然可用。
解决方案
创建 PV ：apiVersion: v1
kind: PersistentVolume
metadata:
name: mysql-pv
spec:
capacity:
storage: 20Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
nfs:
server: 192.168 .1 .100
path: /data/mysql
创建 PVC ：apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 20Gi
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql-deployment
spec:
replicas: 1
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
volumes:
- name: mysql-data
persistentVolumeClaim:
claimName: mysql-pvc
应用配置文件 ：kubectl apply -f mysql-pv.yaml
kubectl apply -f mysql-pvc.yaml
kubectl apply -f mysql-deployment.yaml
验证 PV 和 PVC ：kubectl get pv
kubectl get pvc
验证 PVC 挂载 ：kubectl exec -it mysql-deployment-abcde -- ls /var/lib/mysql
5. 注意事项
PV 和 PVC 的匹配 ：
确保 PVC 的 accessModes 和 storage 需求与 PV 匹配。
存储回收策略 ：
根据实际需求设置 persistentVolumeReclaimPolicy（如 Retain、Delete、Recycle）。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 PV 和 PVC 的配置和操作。
存储性能优化 ：
根据应用场景优化存储性能，如使用 SSD、调整 NFS 配置等。
已深度思考
好的！以下是关于 StorageClass 存储类 和 NFS Provisioner 供应商动态生成 PV 资源 的详细说明：
1. StorageClass 存储类 什么是 StorageClass？
StorageClass 是 Kubernetes 中用于定义存储类型的资源。它允许管理员动态创建 PV（PersistentVolume），并根据用户的需求自动绑定 PVC（PersistentVolumeClaim）。
StorageClass 的作用
动态供应 ：
当用户创建 PVC 时，Kubernetes 会根据 StorageClass 动态创建 PV。
存储类型管理 ：
支持多种存储类型（如 NFS、云存储等），并通过参数配置存储特性。
简化管理 ：
管理员无需手动创建 PV，系统会自动完成 PV 的创建和绑定。
2. NFS Provisioner 供应商动态生成 PV 资源 什么是 NFS Provisioner？
NFS Provisioner 是一个 Kubernetes 插件，用于动态创建 NFS 类型的 PV。它通过 StorageClass 和 PVC 的配置，自动在 NFS 服务器上创建目录，并将其挂载为 PV。
NFS Provisioner 的工作原理
用户创建 PVC ：
动态创建 PV ：
NFS Provisioner 根据 PVC 的需求，在 NFS 服务器上创建目录，并生成 PV。
绑定 PVC 和 PV ：
Kubernetes 将 PVC 与动态创建的 PV 绑定。
3. 实战：使用 NFS Provisioner 动态生成 PV 资源 步骤 1：部署 NFS Provisioner
创建 NFS Provisioner 配置文件 ：apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-provisioner
spec:
replicas: 1
selector:
matchLabels:
app: nfs-provisioner
template:
metadata:
labels:
app: nfs-provisioner
spec:
serviceAccountName: nfs-provisioner
containers:
- name: nfs-provisioner
image: quay.io/kubernetes_incubator/nfs-provisioner:v2.3.0
env:
- name: PROVISIONER_NAME
value: example.com/nfs
- name: NFS_SERVER
value: 192.168 .1 .100
- name: NFS_PATH
value: /data/nfs
volumeMounts:
- name: export-volume
mountPath: /export
volumes:
- name: export-volume
hostPath:
path: /data/nfs
创建 ServiceAccount 和 ClusterRoleBinding ：apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-provisioner
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: nfs-provisioner-role-binding
subjects:
- kind: ServiceAccount
name: nfs-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: rbac.authorization.k8s.io
应用配置文件 ：kubectl apply -f nfs-provisioner.yaml
kubectl apply -f rbac.yaml
步骤 2：创建 StorageClass
创建 StorageClass 配置文件 ：apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: nfs-storage
provisioner: example.com/nfs
parameters:
archiveOnDelete: "false"
应用配置文件 ：kubectl apply -f storageclass.yaml
步骤 3：创建 PVC
创建 PVC 配置文件 ：apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: nfs-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
storageClassName: nfs-storage
应用配置文件 ：kubectl apply -f pvc.yaml
验证 PVC 和 PV ：kubectl get pvc
kubectl get pv
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
nfs-pvc Bound pvc-abcde12345 5 Gi RWX nfs-storage 10 s
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pvc-abcde12345 5 Gi RWX Delete Bound default /nfs-pvc nfs-storage 10 s
步骤 4：挂载 PVC 给 Pod 使用
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: nfs-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: nfs-storage
mountPath: /mnt/data
volumes:
- name: nfs-storage
persistentVolumeClaim:
claimName: nfs-pvc
应用配置文件 ：kubectl apply -f pod.yaml
验证 PVC 挂载 ：kubectl exec -it nfs-pod -- ls /mnt/data
4. 生产案例 场景
一个生产环境中，需要为多个应用动态提供 NFS 存储，并确保存储资源的高效管理。
解决方案
部署 NFS Provisioner ：kubectl apply -f nfs-provisioner.yaml
kubectl apply -f rbac.yaml
创建 StorageClass ：kubectl apply -f storageclass.yaml
创建 PVC ：kubectl apply -f pvc.yaml
挂载 PVC 给应用 Pod ：kubectl apply -f pod.yaml
5. 注意事项
NFS 服务器的配置 ：
确保 NFS 服务器已正确配置，并支持动态创建目录。
StorageClass 的参数 ：
根据实际需求配置 StorageClass 的参数（如 archiveOnDelete）。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 NFS Provisioner 的配置和操作。
存储性能优化 ：
根据应用场景优化存储性能，如使用 SSD、调整 NFS 配置等。
StatefulSet 控制器
1. StatefulSet 控制器 什么是 StatefulSet？
StatefulSet 是 Kubernetes 中用于管理有状态应用的控制器。它为每个 Pod 提供唯一的网络标识和持久化存储，确保 Pod 的顺序性和稳定性。
StatefulSet 的特点
唯一标识 ：
每个 Pod 有唯一的名称（如 web-0、web-1）。
顺序性 ：
持久化存储 ：
每个 Pod 可以绑定独立的 PV（PersistentVolume），确保数据持久化。
2. 控制器部署 Web 站点 步骤
创建 StatefulSet 配置文件 ：apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "web"
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
volumeMounts:
- name: web-data
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: web-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
创建 Service 配置文件 ：apiVersion: v1
kind: Service
metadata:
name: web
spec:
clusterIP: None
selector:
app: web
ports:
- port: 80
targetPort: 80
应用配置文件 ：kubectl apply -f statefulset.yaml
kubectl apply -f service.yaml
验证 StatefulSet 和 Pod ：kubectl get statefulset
kubectl get pods
NAME READY AGE
web 3 / 3 10 s
NAME READY STATUS RESTARTS AGE
web-0 1 / 1 Running 0 10 s
web-1 1 / 1 Running 0 8 s
web-2 1 / 1 Running 0 6 s
3. 实现 Pod 动态扩容与缩容 动态扩容
修改 StatefulSet 的副本数 ：kubectl scale statefulset web --replicas=5
验证扩容结果 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1 / 1 Running 0 10 s
web-1 1 / 1 Running 0 8 s
web-2 1 / 1 Running 0 6 s
web-3 1 / 1 Running 0 4 s
web-4 1 / 1 Running 0 2 s
动态缩容
修改 StatefulSet 的副本数 ：kubectl scale statefulset web --replicas=2
验证缩容结果 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1 / 1 Running 0 10 s
web-1 1 / 1 Running 0 8 s
4. 实现 Pod 更新与回滚 更新 Pod
更新 StatefulSet 的镜像版本 ：kubectl set image statefulset/web nginx=nginx:1.22
验证更新状态 ：kubectl rollout status statefulset/web
statefulset "web" successfully rolled out
查看 Pod 状态 ：kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1 / 1 Running 0 10 s
web-1 1 / 1 Running 0 8 s
web-2 1 / 1 Running 0 6 s
回滚 Pod
查看 StatefulSet 的历史版本 ：kubectl rollout history statefulset/web
REVISION CHANGE-CAUSE
1 <none >
2 <none >
回滚到指定版本 ：kubectl rollout undo statefulset/web --to-revision=1
验证回滚结果 ：kubectl rollout status statefulset/web
kubectl get pods
NAME READY STATUS RESTARTS AGE
web-0 1 / 1 Running 0 10 s
web-1 1 / 1 Running 0 8 s
web-2 1 / 1 Running 0 6 s
5. 生产案例 场景
一个生产环境中，需要为 Web 站点提供稳定的有状态服务，并支持动态扩容、缩容、更新和回滚。
解决方案
创建 StatefulSet ：apiVersion: apps/v1
kind: StatefulSet
metadata:
name: production-web
spec:
serviceName: "production-web"
replicas: 3
selector:
matchLabels:
app: production-web
template:
metadata:
labels:
app: production-web
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80
volumeMounts:
- name: web-data
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: web-data
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
创建 Service ：apiVersion: v1
kind: Service
metadata:
name: production-web
spec:
clusterIP: None
selector:
app: production-web
ports:
- port: 80
targetPort: 80
动态扩容 ：kubectl scale statefulset production-web --replicas=5
动态缩容 ：kubectl scale statefulset production-web --replicas=2
更新 Pod ：kubectl set image statefulset/production-web nginx=nginx:1.22
回滚 Pod ：kubectl rollout undo statefulset/production-web --to-revision=1
6. 注意事项
唯一标识的管理 ：
确保每个 Pod 的唯一标识（如 web-0、web-1）符合业务需求。
持久化存储的配置 ：
根据实际需求配置 volumeClaimTemplates，确保数据持久化。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 StatefulSet 的配置和操作。
更新策略的优化 ：
根据实际需求优化更新策略（如滚动更新、分区更新）。
ConfigMap 配置管理中心
1. ConfigMap 配置管理中心 什么是 ConfigMap？
ConfigMap 是 Kubernetes 中用于存储非敏感配置数据的资源。它将配置数据（如环境变量、配置文件等）与容器镜像解耦，便于管理和更新。
ConfigMap 的作用
配置管理 ：
动态更新 ：
更新 ConfigMap 后，Pod 可以自动加载新的配置。
多环境支持 ：
通过不同的 ConfigMap 支持开发、测试、生产等多环境配置。
2. 通过 YAML 配置文件方式创建 ConfigMap 步骤
创建 ConfigMap 配置文件 ：apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
app.properties: |
server.port=8080
logging.level=INFO
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
应用配置文件 ：kubectl apply -f configmap.yaml
验证 ConfigMap ：kubectl get configmap
kubectl describe configmap my-config
NAME DATA AGE
my-config 2 10 s
3. 通过 kubectl 命令行方式创建 ConfigMap 资源 步骤
从文件创建 ConfigMap ：kubectl create configmap my-config --from-file=app.properties --from-file=nginx.conf
从目录创建 ConfigMap ：kubectl create configmap my-config --from-file=config/
从键值对创建 ConfigMap ：kubectl create configmap my-config --from-literal=server.port=8080 --from-literal=logging.level=INFO
验证 ConfigMap ：kubectl get configmap
kubectl describe configmap my-config
4. 实战：在 Pod 中使用 ConfigMap 步骤
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
env:
- name: SERVER_PORT
valueFrom:
configMapKeyRef:
name: my-config
key: server.port
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/conf.d
volumes:
- name: config-volume
configMap:
name: my-config
items:
- key: nginx.conf
path: nginx.conf
应用配置文件 ：kubectl apply -f pod.yaml
验证 Pod 中的 ConfigMap ：kubectl exec -it my-pod -- cat /etc/nginx/conf.d/nginx.conf
kubectl exec -it my-pod -- printenv SERVER_PORT
5. 生产案例 场景
一个生产环境中，需要为 Web 应用提供动态配置管理，并支持多环境配置。
解决方案
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: production-config
data:
app.properties: |
server.port=8080
logging.level=INFO
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: production-pod
spec:
containers:
- name: nginx
image: nginx
env:
- name: SERVER_PORT
valueFrom:
configMapKeyRef:
name: production-config
key: server.port
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/conf.d
volumes:
- name: config-volume
configMap:
name: production-config
items:
- key: nginx.conf
path: nginx.conf
应用配置文件 ：kubectl apply -f production-configmap.yaml
kubectl apply -f production-pod.yaml
验证 ConfigMap ：kubectl exec -it production-pod -- cat /etc/nginx/conf.d/nginx.conf
kubectl exec -it production-pod -- printenv SERVER_PORT
6. 注意事项
配置数据的安全性 ：
ConfigMap 不适合存储敏感数据（如密码、密钥），应使用 Secret。
配置更新的影响 ：
更新 ConfigMap 后，Pod 需要重启或重新加载配置才能生效。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 ConfigMap 的配置和操作。
配置文件的格式 ：
确保配置文件的格式正确，避免因格式错误导致应用无法加载配置。
使用 ConfigMap
1. Pod 通过变量方式使用 ConfigMap 场景
将 ConfigMap 中的键值对作为环境变量注入到 Pod 的容器中。
步骤
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
server.port: "8080"
logging.level: "INFO"
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
env:
- name: SERVER_PORT
valueFrom:
configMapKeyRef:
name: my-config
key: server.port
- name: LOGGING_LEVEL
valueFrom:
configMapKeyRef:
name: my-config
key: logging.level
应用配置文件 ：kubectl apply -f configmap.yaml
kubectl apply -f pod.yaml
验证环境变量 ：kubectl exec -it my-pod -- printenv SERVER_PORT LOGGING_LEVEL
SERVER_PORT =8080
LOGGING_LEVEL =INFO
2. Pod 通过 volumeMount 使用 ConfigMap 场景
将 ConfigMap 中的配置文件挂载到 Pod 的容器中。
步骤
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/conf.d
volumes:
- name: config-volume
configMap:
name: my-config
items:
- key: nginx.conf
path: nginx.conf
应用配置文件 ：kubectl apply -f configmap.yaml
kubectl apply -f pod.yaml
验证挂载的配置文件 ：kubectl exec -it my-pod -- cat /etc/nginx/conf.d/nginx.conf
3. 使用 ConfigMap 的限制条件
ConfigMap 的大小限制 ：
ConfigMap 的数据大小不能超过 1 MiB。
ConfigMap 的键名限制 ：
键名必须符合 DNS 子域名的命名规则（如 [a-z0-9]([-a-z0-9]*[a-z0-9])?）。
ConfigMap 的更新延迟 ：
更新 ConfigMap 后，Pod 需要重启或重新加载配置才能生效。
ConfigMap 的敏感数据 ：
ConfigMap 不适合存储敏感数据（如密码、密钥），应使用 Secret。
4. ConfigMap 唯一会热更新动作 什么是热更新？
热更新 是指在 Pod 不重启的情况下，动态加载新的配置。
ConfigMap 的热更新机制
通过 volumeMount 挂载的 ConfigMap ：
当 ConfigMap 更新时，Kubernetes 会自动更新挂载的文件内容。
但需要应用支持热加载配置（如 Nginx 的 nginx -s reload）。
通过环境变量注入的 ConfigMap ：
环境变量在 Pod 启动时注入，更新 ConfigMap 后不会自动生效，需要重启 Pod。
实战：实现 ConfigMap 热更新
更新 ConfigMap ：kubectl edit configmap my-config
nginx.conf 的内容：nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
location /status {
stub_status on;
}
}
验证热更新 ：kubectl exec -it my-pod -- cat /etc/nginx/conf.d/nginx.conf
重新加载 Nginx 配置 ：kubectl exec -it my-pod -- nginx -s reload
5. 生产案例 场景
一个生产环境中，需要为 Web 应用提供动态配置管理，并支持热更新。
解决方案
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: production-config
data:
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
创建 Pod ：apiVersion: v1
kind: Pod
metadata:
name: production-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/conf.d
volumes:
- name: config-volume
configMap:
name: production-config
items:
- key: nginx.conf
path: nginx.conf
应用配置文件 ：kubectl apply -f production-configmap.yaml
kubectl apply -f production-pod.yaml
验证热更新 ：
更新 ConfigMap 后，查看挂载的配置文件内容，并重新加载 Nginx 配置。
6. 注意事项
应用的热加载支持 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 ConfigMap 的配置和操作。
配置文件的格式 ：
确保配置文件的格式正确，避免因格式错误导致应用无法加载配置。
ConfigMap 的更新频率 ：
避免频繁更新 ConfigMap，以免影响应用性能。
subPath和Reloader实现资源热更新
1. 使用 subPath 挂载 ConfigMap 什么是 subPath？
subPath 是 Kubernetes 中用于将 ConfigMap 或 Volume 中的单个文件或目录挂载到容器中的指定路径。它允许将多个文件挂载到同一个目录下，而不会覆盖整个目录。
使用场景
将 ConfigMap 中的单个配置文件挂载到容器的特定路径。
避免挂载整个 ConfigMap 时覆盖容器中的其他文件。
实战：使用 subPath 挂载 ConfigMap
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
data:
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
app.properties: |
server.port=8080
logging.level=INFO
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
- name: config-volume
mountPath: /app/config/app.properties
subPath: app.properties
volumes:
- name: config-volume
configMap:
name: my-config
应用配置文件 ：kubectl apply -f configmap.yaml
kubectl apply -f pod.yaml
验证挂载的配置文件 ：kubectl exec -it my-pod -- cat /etc/nginx/nginx.conf
kubectl exec -it my-pod -- cat /app/config/app.properties
2. Reloader 实现 ConfigMap 或 Secret 资源热更新 什么是 Reloader？
Reloader 是一个 Kubernetes 控制器，用于监控 ConfigMap 和 Secret 的变化，并自动重启相关的 Pod 以实现热更新。它通过注解（Annotation）标记需要监控的资源，并在资源更新时触发 Pod 的重启。
使用场景
当 ConfigMap 或 Secret 更新时，自动重启相关的 Pod 以加载新的配置。
避免手动重启 Pod，提高运维效率。
实战：使用 Reloader 实现热更新
安装 Reloader ：helm repo add stakater https://stakater.github.io/stakater-charts
helm repo update
helm install reloader stakater/reloader
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: my-config
annotations:
reloader.stakater.com/auto: "true"
data:
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
annotations:
reloader.stakater.com/auto: "true"
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: config-volume
configMap:
name: my-config
应用配置文件 ：kubectl apply -f configmap.yaml
kubectl apply -f deployment.yaml
更新 ConfigMap ：kubectl edit configmap my-config
nginx.conf 的内容：nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
location /status {
stub_status on;
}
}
验证热更新 ：kubectl get pods -w
NAME READY STATUS RESTARTS AGE
my -deployment-5 f7b5f6c4b-abcde 1 /1 Running 0 10 s
my -deployment-5 f7b5f6c4b-fghij 1 /1 Running 0 8 s
3. 生产案例 场景
一个生产环境中，需要为 Web 应用提供动态配置管理，并支持热更新。
解决方案
安装 Reloader ：helm install reloader stakater/reloader
创建 ConfigMap ：apiVersion: v1
kind: ConfigMap
metadata:
name: production-config
annotations:
reloader.stakater.com/auto: "true"
data:
nginx.conf: |
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html;
}
}
创建 Deployment ：apiVersion: apps/v1
kind: Deployment
metadata:
name: production-deployment
annotations:
reloader.stakater.com/auto: "true"
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: config-volume
mountPath: /etc/nginx/nginx.conf
subPath: nginx.conf
volumes:
- name: config-volume
configMap:
name: production-config
应用配置文件 ：kubectl apply -f production-configmap.yaml
kubectl apply -f production-deployment.yaml
验证热更新 ：
更新 ConfigMap 后，查看 Pod 是否被重启，并验证新的配置是否生效。
4. 注意事项
Reloader 的安装 ：
确保 Reloader 正确安装，并监控到需要热更新的资源。
注解的使用 ：
通过 reloader.stakater.com/auto: "true" 注解标记需要监控的资源。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Reloader 的配置和操作。
资源更新的频率 ：
避免频繁更新 ConfigMap 或 Secret，以免影响应用性能。
Secret
1. Secret 什么是 Secret？
Secret 是 Kubernetes 中用于存储敏感数据（如密码、密钥、证书等）的资源。它与 ConfigMap 类似，但数据会以 Base64 编码存储，提供更高的安全性。
Secret 的作用
敏感数据管理 ：
安全性 ：
数据以 Base64 编码存储，提供基本的安全保护。
动态更新 ：
更新 Secret 后，Pod 可以自动加载新的数据。
2. Pod 通过环境变量方式使用 Secret 场景
将 Secret 中的键值对作为环境变量注入到 Pod 的容器中。
步骤
创建 Secret ：apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
username: YWRtaW4=
password: cGFzc3dvcmQ=
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
env:
- name: USERNAME
valueFrom:
secretKeyRef:
name: my-secret
key: username
- name: PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: password
应用配置文件 ：kubectl apply -f secret.yaml
kubectl apply -f pod.yaml
验证环境变量 ：kubectl exec -it my-pod -- printenv USERNAME PASSWORD
USERNAME =admin
PASSWORD =password
3. Pod 通过 volumeMount 使用 Secret 场景
将 Secret 中的文件挂载到 Pod 的容器中。
步骤
创建 Secret ：apiVersion: v1
kind: Secret
metadata:
name: my-secret
type: Opaque
data:
config.ini: |
[database]
username=YWRtaW4=
password=cGFzc3dvcmQ=
创建 Pod 配置文件 ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: secret-volume
mountPath: /etc/secret
volumes:
- name: secret-volume
secret:
secretName: my-secret
items:
- key: config.ini
path: config.ini
应用配置文件 ：kubectl apply -f secret.yaml
kubectl apply -f pod.yaml
验证挂载的文件 ：kubectl exec -it my-pod -- cat /etc/secret/config.ini
4. TLS Secret 配置 HTTPS Web 站点 场景
使用 TLS Secret 为 Web 站点配置 HTTPS。
步骤
生成 TLS 证书和密钥 ：openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout tls.key -out tls.crt -subj "/CN=example.com"
创建 TLS Secret ：kubectl create secret tls tls-secret --cert=tls.crt --key=tls.key
创建 Deployment 和 Service ：apiVersion: apps/v1
kind: Deployment
metadata:
name: https-web
spec:
replicas: 1
selector:
matchLabels:
app: https-web
template:
metadata:
labels:
app: https-web
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 443
volumeMounts:
- name: tls-secret
mountPath: /etc/nginx/ssl
volumes:
- name: tls-secret
secret:
secretName: tls-secret
---
apiVersion: v1
kind: Service
metadata:
name: https-web
spec:
type: NodePort
selector:
app: https-web
ports:
- port: 443
targetPort: 443
nodePort: 30443
应用配置文件 ：kubectl apply -f https-web.yaml
验证 HTTPS Web 站点 ：
使用浏览器访问 https://<NodeIP>:30443，确认站点可以正常访问。
5. 生产案例 场景
一个生产环境中，需要为 Web 应用提供 HTTPS 支持，并确保敏感数据的安全性。
解决方案
创建 TLS Secret ：kubectl create secret tls production-tls-secret --cert=tls.crt --key=tls.key
创建 Deployment 和 Service ：apiVersion: apps/v1
kind: Deployment
metadata:
name: production-https-web
spec:
replicas: 3
selector:
matchLabels:
app: production-https-web
template:
metadata:
labels:
app: production-https-web
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 443
volumeMounts:
- name: tls-secret
mountPath: /etc/nginx/ssl
volumes:
- name: tls-secret
secret:
secretName: production-tls-secret
---
apiVersion: v1
kind: Service
metadata:
name: production-https-web
spec:
type: LoadBalancer
selector:
app: production-https-web
ports:
- port: 443
targetPort: 443
应用配置文件 ：kubectl apply -f production-https-web.yaml
验证 HTTPS Web 站点 ：
使用浏览器访问 https://<LoadBalancerIP>，确认站点可以正常访问。
6. 注意事项
Secret 的安全性 ：
确保 Secret 的访问权限受到严格控制，避免敏感数据泄露。
TLS 证书的管理 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Secret 的配置和操作。
应用的热加载支持 ：
RBAC
1. RBAC（基于角色的访问控制） 什么是 RBAC？
RBAC（Role-Based Access Control） 是 Kubernetes 中用于管理用户和服务账户访问权限的机制。它通过角色（Role）和角色绑定（RoleBinding）来定义和分配权限，确保资源的安全访问。
2. 认证（Authentication） 什么是认证？
认证 是 Kubernetes 中验证用户或服务账户身份的过程。它确保只有合法的用户或服务账户可以访问集群资源。
认证方式
X.509 客户端证书 ：
Bearer Token ：
ServiceAccount Token ：
OpenID Connect（OIDC） ：
3. 授权（Authorization） 什么是授权？
授权 是 Kubernetes 中确定用户或服务账户是否有权限执行特定操作的过程。它基于 RBAC 机制，通过角色和角色绑定来分配权限。
授权方式
RBAC ：
ABAC（基于属性的访问控制） ：
Node Authorization ：
Webhook ：
4. 准入控制（Admission Control） 什么是准入控制？
准入控制 是 Kubernetes 中在请求被处理之前进行额外验证和修改的机制。它确保请求符合集群的安全策略和资源限制。
常见的准入控制器
NamespaceLifecycle ：
LimitRanger ：
ResourceQuota ：
PodSecurityPolicy ：
5. RBAC 的组成 RBAC 的核心组件
Role ：
ClusterRole ：
RoleBinding ：
ClusterRoleBinding ：
6. 实战：使用 RBAC 管理权限 场景
为用户 alice 授予 default 命名空间中 Pod 的只读权限。
步骤
创建 Role ：apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: ["" ]
resources: ["pods" ]
verbs: ["get" , "watch" , "list" ]
创建 RoleBinding ：apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
应用配置文件 ：kubectl apply -f role.yaml
kubectl apply -f rolebinding.yaml
验证权限 ：kubectl auth can-i get pods --as=alice
yes，表示 alice 有权限读取 Pod。
7. 生产案例 场景
一个生产环境中，需要为不同团队分配不同的权限，确保资源的安全访问。
解决方案
创建 ClusterRole ：apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: team-admin
rules:
- apiGroups: ["" ]
resources: ["*" ]
verbs: ["*" ]
创建 ClusterRoleBinding ：apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: team-admin-binding
subjects:
- kind: Group
name: team-a
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: team-admin
apiGroup: rbac.authorization.k8s.io
应用配置文件 ：kubectl apply -f clusterrole.yaml
kubectl apply -f clusterrolebinding.yaml
验证权限 ：kubectl auth can-i create pods --as=team-a
yes，表示 team-a 有权限创建 Pod。
8. 注意事项
最小权限原则 ：
为用户或服务账户分配最小必要的权限，避免过度授权。
定期审计权限 ：
定期检查和清理不再使用的 Role 和 RoleBinding。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 RBAC 的配置和操作。
权限的继承性 ：
UserAccount和ServiceAccount应用
1. UserAccount 和 ServiceAccount UserAccount
UserAccount 是 Kubernetes 中用于表示外部用户的账户。它通常由集群管理员手动创建，用于管理集群资源的访问权限。
示例：alice、bob。
ServiceAccount
ServiceAccount 是 Kubernetes 中用于表示内部服务或 Pod 的账户。它由 Kubernetes 自动创建，用于 Pod 与 Kubernetes API 的交互。
示例：default、kube-system。
2. ServiceAccount 应用案例 场景
为 Pod 分配一个 ServiceAccount，使其可以访问 Kubernetes API。
步骤
创建 ServiceAccount ：apiVersion: v1
kind: ServiceAccount
metadata:
name: my-serviceaccount
创建 Pod 并使用 ServiceAccount ：apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
serviceAccountName: my-serviceaccount
containers:
- name: nginx
image: nginx
应用配置文件 ：kubectl apply -f serviceaccount.yaml
kubectl apply -f pod.yaml
验证 ServiceAccount ：kubectl describe pod my-pod
Service Account: my -serviceaccount
3. Role（角色）应用 场景
在 default 命名空间中创建一个 Role，授予 Pod 的只读权限。
步骤
创建 Role ：apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: ["" ]
resources: ["pods" ]
verbs: ["get" , "watch" , "list" ]
应用配置文件 ：kubectl apply -f role.yaml
验证 Role ：kubectl get role pod-reader -n default
4. ClusterRole（集群角色）应用 场景
创建一个 ClusterRole，授予整个集群中 Pod 的只读权限。
步骤
创建 ClusterRole ：apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: pod-reader
rules:
- apiGroups: ["" ]
resources: ["pods" ]
verbs: ["get" , "watch" , "list" ]
应用配置文件 ：kubectl apply -f clusterrole.yaml
验证 ClusterRole ：kubectl get clusterrole pod-reader
5. RoleBinding（角色绑定）应用 场景
将 pod-reader Role 绑定到 default 命名空间中的用户 alice。
步骤
创建 RoleBinding ：apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: alice
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
应用配置文件 ：kubectl apply -f rolebinding.yaml
验证 RoleBinding ：kubectl get rolebinding read-pods -n default
6. ClusterRoleBinding（集群角色绑定）应用 场景
将 pod-reader ClusterRole 绑定到整个集群中的用户 admin。
步骤
创建 ClusterRoleBinding ：apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods
subjects:
- kind: User
name: admin
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: pod-reader
apiGroup: rbac.authorization.k8s.io
应用配置文件 ：kubectl apply -f clusterrolebinding.yaml
验证 ClusterRoleBinding ：kubectl get clusterrolebinding read-pods
7. 生产案例 场景
一个生产环境中，需要为不同团队分配不同的权限，确保资源的安全访问。
解决方案
创建 ClusterRole ：apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: team-admin
rules:
- apiGroups: ["" ]
resources: ["*" ]
verbs: ["*" ]
创建 ClusterRoleBinding ：apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: team-admin-binding
subjects:
- kind: Group
name: team-a
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: team-admin
apiGroup: rbac.authorization.k8s.io
应用配置文件 ：kubectl apply -f clusterrole.yaml
kubectl apply -f clusterrolebinding.yaml
验证权限 ：kubectl auth can-i create pods --as=team-a
yes，表示 team-a 有权限创建 Pod。
8. 注意事项
最小权限原则 ：
为用户或服务账户分配最小必要的权限，避免过度授权。
定期审计权限 ：
定期检查和清理不再使用的 Role 和 RoleBinding。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 RBAC 的配置和操作。
权限的继承性 ：
Kubectl资源操作
1. Kubectl 对 ServiceAccount 资源操作 创建 ServiceAccount kubectl create serviceaccount my-serviceaccount
查看 ServiceAccount kubectl get serviceaccount my-serviceaccount
删除 ServiceAccount kubectl delete serviceaccount my-serviceaccount
描述 ServiceAccount kubectl describe serviceaccount my-serviceaccount
2. Kubectl 对 Role 资源操作 创建 Role kubectl create role pod-reader --verb=get,list,watch --resource=pods
查看 Role kubectl get role pod-reader
删除 Role kubectl delete role pod-reader
描述 Role kubectl describe role pod-reader
3. Kubectl 对 ClusterRole 资源操作 创建 ClusterRole kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods
查看 ClusterRole kubectl get clusterrole pod-reader
删除 ClusterRole kubectl delete clusterrole pod-reader
描述 ClusterRole kubectl describe clusterrole pod-reader
4. Kubectl 对 RoleBinding 资源操作 创建 RoleBinding kubectl create rolebinding read-pods --role=pod-reader --user=alice
查看 RoleBinding kubectl get rolebinding read-pods
删除 RoleBinding kubectl delete rolebinding read-pods
描述 RoleBinding kubectl describe rolebinding read-pods
5. Kubectl 对 ClusterRoleBinding 资源操作 创建 ClusterRoleBinding kubectl create clusterrolebinding read-pods --clusterrole=pod-reader --user=admin
查看 ClusterRoleBinding kubectl get clusterrolebinding read-pods
删除 ClusterRoleBinding kubectl delete clusterrolebinding read-pods
描述 ClusterRoleBinding kubectl describe clusterrolebinding read-pods
6. 限制不同的用户操作 Kubernetes 集群 场景
为用户 alice 授予 default 命名空间中 Pod 的只读权限。
为用户 bob 授予 default 命名空间中 Pod 的读写权限。
步骤
创建 Role ：kubectl create role pod-reader --verb=get,list,watch --resource=pods
kubectl create role pod-writer --verb=get,list,watch,create,update,delete --resource=pods
创建 RoleBinding ：kubectl create rolebinding read-pods --role=pod-reader --user=alice
kubectl create rolebinding write-pods --role=pod-writer --user=bob
验证权限 ：kubectl auth can-i get pods --as=alice
kubectl auth can-i create pods --as=bob
yes，表示 alice 有权限读取 Pod，bob 有权限创建 Pod。
7. 生产案例 场景
一个生产环境中，需要为不同团队分配不同的权限，确保资源的安全访问。
解决方案
创建 ClusterRole ：kubectl create clusterrole team-admin --verb=* --resource=*
创建 ClusterRoleBinding ：kubectl create clusterrolebinding team-admin-binding --clusterrole=team-admin --group=team-a
验证权限 ：kubectl auth can-i create pods --as=team-a
yes，表示 team-a 有权限创建 Pod。
8. 注意事项
最小权限原则 ：
为用户或服务账户分配最小必要的权限，避免过度授权。
定期审计权限 ：
定期检查和清理不再使用的 Role 和 RoleBinding。
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 RBAC 的配置和操作。
权限的继承性 ：
Ingress
1. 在 Kubernetes 中为什么要做负载均衡？ 原因
高可用性 ：
负载均衡可以将流量分发到多个 Pod，避免单点故障，提高应用的可用性。
扩展性 ：
负载均衡可以根据流量动态扩展或缩减 Pod 数量，确保应用的高性能。
流量管理 ：
负载均衡可以根据规则（如路径、域名）将流量分发到不同的服务，实现灵活的流量管理。
安全性 ：
负载均衡可以提供 SSL/TLS 终止、访问控制等安全功能，保护应用的安全。
2. Ingress 和 Ingress Controller 什么是 Ingress？
Ingress 是 Kubernetes 中用于管理外部访问的 API 对象。它通过定义规则（如路径、域名）将外部流量路由到集群内部的服务。
什么是 Ingress Controller？
Ingress Controller 是 Kubernetes 中用于实现 Ingress 规则的控制器。它负责监听 Ingress 资源的变化，并根据规则配置负载均衡器（如 Nginx、Traefik）。
3. Ingress Controller 代理 Kubernetes 内部应用的流程 流程
用户访问应用 ：
用户通过域名或 IP 访问 Kubernetes 集群中的应用。
Ingress Controller 监听流量 ：
Ingress Controller 监听外部流量，并根据 Ingress 规则进行路由。
流量路由到 Service ：
Ingress Controller 将流量路由到对应的 Kubernetes Service。
Service 转发到 Pod ：
Service 将流量转发到后端的 Pod，完成请求处理。
4. Ingress 应用场景 场景
基于域名的路由 ：
基于路径的路由 ：
SSL/TLS 终止 ：
在 Ingress 层终止 SSL/TLS，减轻后端服务的负担。
访问控制 ：
通过 Ingress 实现 IP 白名单、Basic Auth 等访问控制。
5. 安装部署 Nginx Ingress Controller 步骤
添加 Helm 仓库 ：helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
安装 Nginx Ingress Controller ：helm install ingress-nginx ingress-nginx/ingress-nginx
验证安装 ：kubectl get pods -n default -l app.kubernetes.io/name=ingress-nginx
NAME READY STATUS RESTARTS AGE
ingress- nginx- controller-5 f7b5f6c4b- abcde 1 / 1 Running 0 10 s
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
应用 Ingress 配置文件 ：kubectl apply -f ingress.yaml
验证 Ingress ：kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
example-ingress nginx example.com 192.168 .1.100 80 10 s
6. 生产案例 场景
一个生产环境中，需要为多个 Web 应用提供基于域名的路由和 SSL/TLS 终止。
解决方案
安装 Nginx Ingress Controller ：helm install ingress-nginx ingress-nginx/ingress-nginx
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: production-ingress
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
tls:
- hosts:
- example.com
secretName: example-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
应用 Ingress 配置文件 ：kubectl apply -f production-ingress.yaml
验证 Ingress ：kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
production-ingress nginx example.com 192.168 .1.100 80 , 443 10 s
7. 注意事项
Ingress Controller 的选择 ：
根据实际需求选择合适的 Ingress Controller（如 Nginx、Traefik）。
SSL/TLS 证书的管理 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Ingress 的配置和操作。
访问控制 ：
通过 Ingress 实现 IP 白名单、Basic Auth 等访问控制，确保应用的安全。
Ingress 资源清单编写与策略配置
1. Ingress 资源清单编写与策略配置技巧 Ingress 资源清单编写 策略配置技巧
路径重写 ：
SSL/TLS 终止 ：
访问控制 ：
2. Ingress HTTP 代理 Web 站点 场景
使用 Ingress 将 HTTP 流量代理到 Kubernetes 内部的 Web 站点。
步骤
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: http-ingress
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
应用配置文件 ：kubectl apply -f http-ingress.yaml
验证 Ingress ：kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
http-ingress nginx example.com 192.168 .1.100 80 10 s
3. Ingress HTTPS 代理 Web 站点 场景
使用 Ingress 将 HTTPS 流量代理到 Kubernetes 内部的 Web 站点。
步骤
生成 TLS 证书和密钥 ：openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout tls.key -out tls.crt -subj "/CN=example.com"
创建 TLS Secret ：kubectl create secret tls example-tls --cert=tls.crt --key=tls.key
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: https-ingress
spec:
tls:
- hosts:
- example.com
secretName: example-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
应用配置文件 ：kubectl apply -f https-ingress.yaml
验证 Ingress ：kubectl get ingress
NAME CLASS HOSTS ADDRESS PORTS AGE
https-ingress nginx example.com 192.168 .1.100 80 , 443 10 s
4. Nginx Ingress 添加 Basic Auth 安全认证 场景
使用 Nginx Ingress 为 Web 站点添加 Basic Auth 安全认证。
步骤
生成 Basic Auth 文件 ：htpasswd -c auth admin
创建 Basic Auth Secret ：kubectl create secret generic basic-auth --from-file=auth
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: basic-auth-ingress
annotations:
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: basic-auth
nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
应用配置文件 ：kubectl apply -f basic-auth-ingress.yaml
验证 Basic Auth ：
访问 http://example.com，会弹出 Basic Auth 认证窗口。
5. 生产案例 场景
一个生产环境中，需要为 Web 站点提供 HTTPS 支持和 Basic Auth 安全认证。
解决方案
生成 TLS 证书和密钥 ：openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
-keyout tls.key -out tls.crt -subj "/CN=example.com"
创建 TLS Secret ：kubectl create secret tls example-tls --cert=tls.crt --key=tls.key
生成 Basic Auth 文件 ：htpasswd -c auth admin
创建 Basic Auth Secret ：kubectl create secret generic basic-auth --from-file=auth
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: production-ingress
annotations:
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: basic-auth
nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
spec:
tls:
- hosts:
- example.com
secretName: example-tls
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: example-service
port:
number: 80
应用配置文件 ：kubectl apply -f production-ingress.yaml
验证 HTTPS 和 Basic Auth ：
访问 https://example.com，会弹出 Basic Auth 认证窗口。
6. 注意事项
证书和密钥的管理 ：
Basic Auth 的安全性 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证 Ingress 的配置和操作。
访问控制 ：
通过 Ingress 实现 IP 白名单、Basic Auth 等访问控制，确保应用的安全。
流量切分
1. 基于服务权重的流量切分 场景
将流量按权重比例分发到不同的服务版本，实现灰度发布或 A/B 测试。
步骤
创建多个 Service ：
例如，创建 service-v1 和 service-v2。
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: weighted-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "20"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-v1
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: service-v2
port:
number: 80
应用配置文件 ：kubectl apply -f weighted-ingress.yaml
验证流量切分 ：
访问 http://example.com，80% 的流量会分发到 service-v1，20% 的流量会分发到 service-v2。
2. 基于客户端请求头的流量切分 场景
根据客户端请求头（如 User-Agent、Cookie）将流量分发到不同的服务版本。
步骤
创建多个 Service ：
例如，创建 service-v1 和 service-v2。
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: header-based-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "User-Agent"
nginx.ingress.kubernetes.io/canary-by-header-value: "mobile"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-v1
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: service-v2
port:
number: 80
应用配置文件 ：kubectl apply -f header-based-ingress.yaml
验证流量切分 ：
使用 User-Agent: mobile 的请求会分发到 service-v2，其他请求会分发到 service-v1。
3. 基于客户端来源 IP 的流量切分 场景
根据客户端来源 IP 将流量分发到不同的服务版本。
步骤
创建多个 Service ：
例如，创建 service-v1 和 service-v2。
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ip-based-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-ip: "192.168.1.100"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-v1
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: service-v2
port:
number: 80
应用配置文件 ：kubectl apply -f ip-based-ingress.yaml
验证流量切分 ：
来自 192.168.1.100 的请求会分发到 service-v2，其他请求会分发到 service-v1。
4. 生产案例 场景
一个生产环境中，需要根据客户端请求头和来源 IP 将流量分发到不同的服务版本。
解决方案
创建多个 Service ：
例如，创建 service-v1 和 service-v2。
创建 Ingress 资源 ：apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: production-ingress
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "User-Agent"
nginx.ingress.kubernetes.io/canary-by-header-value: "mobile"
nginx.ingress.kubernetes.io/canary-by-ip: "192.168.1.100"
spec:
rules:
- host: example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: service-v1
port:
number: 80
- path: /
pathType: Prefix
backend:
service:
name: service-v2
port:
number: 80
应用配置文件 ：kubectl apply -f production-ingress.yaml
验证流量切分 ：
使用 User-Agent: mobile 或来自 192.168.1.100 的请求会分发到 service-v2，其他请求会分发到 service-v1。
5. 注意事项
流量切分的准确性 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证流量切分的配置和操作。
灰度发布的策略 ：
根据实际需求选择合适的灰度发布策略（如权重、请求头、来源 IP）。
监控和日志 ：
监控流量切分的效果，并记录日志以便分析和排查问题。
好的！以下是关于 Etcd 在 Kubernetes 集群中的作用 、Etcd 集群选举算法 、Etcd 基本操作 、Etcd 快照备份 和 Etcd 快照还原 的详细说明：
1. Etcd 在 Kubernetes 集群中的作用 什么是 Etcd？
Etcd 是一个分布式键值存储系统，用于存储 Kubernetes 集群的所有关键数据（如集群状态、配置、元数据等）。它是 Kubernetes 的核心组件之一，负责保证集群数据的一致性和高可用性。
Etcd 的作用
存储集群状态 ：
存储 Kubernetes 集群的所有资源对象（如 Pod、Service、Deployment 等）的状态。
配置管理 ：
存储 Kubernetes 集群的配置信息（如网络配置、安全策略等）。
服务发现 ：
存储 Kubernetes 集群中服务的注册和发现信息。
高可用性 ：
2. Etcd 集群选举算法 Raft 算法
Raft 是 Etcd 使用的分布式一致性算法，用于实现集群的选举和数据同步。
选举过程
Leader 选举 ：
当集群中的 Leader 节点失效时，其他节点会发起选举，选出新的 Leader。
日志复制 ：
Leader 节点将数据变更日志复制到其他节点，确保数据一致性。
故障恢复 ：
当节点发生故障时，Raft 算法会自动恢复集群的正常运行。
3. Etcd 基本操作 启动 Etcd etcd
查看 Etcd 版本 etcdctl version
写入数据 etcdctl put /key value
读取数据 etcdctl get /key
删除数据 etcdctl del /key
列出所有键 etcdctl get / --prefix
4. Etcd 快照备份 场景 步骤
创建快照 ：etcdctl snapshot save snapshot.db
查看快照状态 ：etcdctl snapshot status snapshot.db
备份快照文件 ：
将 snapshot.db 文件备份到安全的位置。
5. Etcd 快照还原 场景
当 Etcd 数据丢失或损坏时，使用快照文件恢复数据。
步骤
停止 Etcd 服务 ：systemctl stop etcd
还原快照 ：etcdctl snapshot restore snapshot.db --data-dir /var/lib/etcd
启动 Etcd 服务 ：systemctl start etcd
验证数据 ：etcdctl get / --prefix
6. 生产案例 场景
一个生产环境中，需要定期备份 Etcd 数据，并在数据丢失时快速恢复。
解决方案
创建快照 ：etcdctl snapshot save /backup/snapshot.db
备份快照文件 ：
将 /backup/snapshot.db 文件备份到远程存储（如 S3、NFS）。
还原快照 ：etcdctl snapshot restore /backup/snapshot.db --data-dir /var/lib/etcd
启动 Etcd 服务 ：systemctl start etcd
验证数据 ：etcdctl get / --prefix
7. 注意事项
快照的定期备份 ：
快照的存储安全 ：
生产环境的测试 ：
在生产环境中使用前，先在测试环境中验证快照备份和还原的配置和操作。
监控和日志 ：
监控 Etcd 的运行状态，并记录日志以便分析和排查问题。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布：重大改进与新特性概览！
· AI与.NET技术实操系列（二）：开始使用ML.NET
· .NET10 - 预览版1新功能体验（一）