Kubernetes流量路由、状态管理及集群部署全解析

# Kubernetes 流量路由、状态管理及集群部署全解析 ## 1. 流量路由到 Kubernetes 将外部流量引入 Kubernetes 集群有多种方式，下面详细介绍每种方式的工作原理。 ### 1.1 Cluster IP Cluster IP 仅提供 Kubernetes 集群内部的访问权限。集群内的其他应用可以访问该服务，但无法从外部访问。以下是 Cluster IP 的定义示例： ```yaml apiVersion: v1 kind: Service metadata: name: product-web spec: selector: app: product-web type: ClusterIP ports: - name: http port: 80 targetPort: 80 protocol: TCP ``` 若要从外部访问该服务，可使用 Kubernetes 代理。启动代理的命令如下： ```bash (base) binildass-MacBook-Pro:ch10-01 binil$ kubectl proxy --port=8080 ``` 此命令会在本地主机和 Kubernetes API 服务器之间创建一个代理服务器或应用层网关，所有传入数据通过一个端口进入，并转发到远程 Kubernetes API 服务器端口。 ### 1.2 NodePorts 将服务暴露为 NodePort 服务时，每个集群节点会在自身开放一个端口，并将该端口接收到的流量重定向到相应的服务。服务不仅可以通过内部集群 IP 和端口访问，还能通过所有节点或虚拟机上的专用端口访问。NodePort 是将外部流量直接引入服务的最原始方式。以下是 NodePort 的定义示例： ```yaml apiVersion: v1 kind: Service metadata: name: product-server-nodeport spec: selector: app: product-server ports: - nodePort: 30002 port: 8081 targetPort: 8081 type: NodePort ``` NodePort 只能使用 30000 到 32767 之间的端口，若未指定，则使用随机端口。由于服务跨节点分布，第一个节点端口接收到的连接可能会转发到同一节点上运行的 Pod，也可能转发到其他节点上运行的 Pod 之一。 ### 1.3 Load Balancer 使用负载均衡器可以将服务暴露到互联网。这使得服务可以通过从 Kubernetes 运行所在的云基础设施中配置的专用负载均衡器进行访问。以下是 Load Balancer 的定义示例： ```yaml apiVersion: v1 kind: Service metadata: name: product-web spec: selector: app: product-web type: LoadBalancer ports: - port: 8765 targetPort: 80 ``` 使用负载均衡器时，没有路由或过滤操作，指定的所有流量都将转发到服务。不过，每个暴露的服务都会获得自己的 IP 地址，并且需要为所有暴露的服务分别支付一个负载均衡器的费用。 ### 1.4 Ingress Ingress 可以通过单个 IP 地址暴露多个服务。它在 HTTP 层（网络层 7）运行，因此具有成本效益。Ingress 有多种类型，具有不同的功能。以下是一个包含两条规则的 Ingress 定义示例： ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-service annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: "adminer.acme.test" http: paths: - path: / pathType: Prefix backend: service: name: adminer port: number: 8080 - host: "products.acme.test" http: paths: - path: / pathType: Prefix backend: service: name: product-web port: number: 8080 ``` 上述规则确保 Ingress 控制器接收到的所有 HTTP 请求中，请求 `products.acme.test` 主机的请求将发送到端口 8080 上的 `product-web` 服务，请求 `adminer.acme.test` 主机的请求将发送到端口 8080 上的 `adminer` 服务。 ## 2. 状态管理 ### 2.1 扩展与状态管理 虽然弹性扩展架构很理想，但状态管理会带来一些问题。若组件要真正实现无状态，就应像银行柜员一样，每次服务你的不是同一个人。同样，后续的每个事务都可以由类似组件的任何其他实例处理。这意味着，除了客户端设备和持久存储外，其他所有中间组件都必须是无状态的。在客户端层无法避免状态，因为没有状态就无法进行个性化设置，这会影响用户体验。对于非简单应用程序，通常需要在某种数据库中管理一定的状态。 ### 2.2 StatefulSets 为解决状态管理问题，StatefulSet 表示一组唯一、持久且具有稳定 Pod 名称的 Pod。对于无状态的 DeploymentSet，每次部署或重启 Pod 时，都会得到不同的 Pod 名称。而使用 StatefulSet，即使部署重启，也会得到相同的 Pod 名称（如 `mongo-cluster-0`）。 ### 2.3 持久卷声明（Persistent Volume Claim，PVC） 持久卷声明是 Pod 对存储的需求声明，在 Pod 的生命周期的某个时刻，该需求可以得到满足。持久卷声明承诺在某个时刻将“转换”为应用程序可以使用的特定平台存储卷，具有定义的特性，如类、大小和访问模式（ROX：ReadOnlyMany，RWO：ReadWriteOnce，RWX：ReadWriteMany）。这样可以将特定存储实现的链接从 Pod/部署中抽象出来。 ### 2.4 持久卷（Persistent Volume，PV） 持久卷是 Kubernetes 集群中的一块存储，由服务器/存储/集群管理员配置或使用某些存储类动态配置。它是集群中的一种资源，就像节点一样。如果 Kubernetes 没有你所需