K8s之端口暴露（ThePortofK8sisExposed）

K8s 之端口暴露

Kubernetes 是一个用于管理容器化应用程序的流行工具。然而，关于它的工作原理存在一些误解。最常见的误解之一是关于 Kubernetes Pod 中的端口暴露。本文将解释 Kubernetes 中端口暴露的真相。

1 误解

像许多 Kubernetes 新手一样，我最初认为只有在 Pod 清单中指定的端口才会被暴露和访问。YAML 文件中的 ports 字段似乎是一个定义哪些端口应该被打开的自然位置，就像配置传统防火墙一样。这种假设让我认为任何未明确声明的端口都将被关闭且无法访问。

这种误解是可以理解的。毕竟，在许多其他系统中，明确定义开放端口是一种常见的安全实践。然而，对于 Kubernetes 来说，情况有所不同。

2  Kubernetes 网络的实际工作原理

要理解 Kubernetes 中的端口暴露，我们首先需要了解 Kubernetes 网络的基础知识。Kubernetes 遵循一种扁平网络模型，默认情况下，所有 Pod 都可以相互通信，无论它们运行在哪个节点上。这是通过容器网络接口（CNI）实现的，CNI 是一个为容器设置网络的插件。

在这种模型中，每个 Pod 在集群网络中都有自己的 IP 地址。这个 IP 地址在集群内是完全可路由的，这意味着任何 Pod 都可以使用该 IP 地址访问其他 Pod。

3 端口暴露的真相

关键点如下：

在 Kubernetes 中，默认情况下，集群网络内的所有端口都是潜在可访问的。

Pod 或容器清单中的 ports 字段主要用于文档和服务发现目的。它实际上并不限制或控制对这些端口的网络流量。

这意味着，如果你的容器中的进程正在监听某个端口，那么该端口可以从集群中的其他 Pod 访问，无论你是否在 YAML 清单中指定了它。

4 行为演示

让我们通过一个实际示例来说明这种行为：我们将创建一个简单的 Pod，运行一个监听端口 8080、9090 和 5000 的 Python 应用程序。

import http.server import socketserver from http.server import SimpleHTTPRequestHandler import threading class CustomHandler(SimpleHTTPRequestHandler):     def do_GET(self):         self.send_response(200)         self.send_header('Content-type', 'text/plain')         self.end_headers()         response = f"Hello from port {self.server.server_address[1]}!"         self.wfile.write(response.encode()) def run_server(port):     with socketserver.TCPServer(("", port), CustomHandler) as httpd:         print(f"Serving on port {port}")         httpd.serve_forever() if __name__ == "__main__":     ports = [8080, 9090, 5000]     threads = []     for port in ports:         thread = threading.Thread(target=run_server, args=(port,))         threads.append(thread)         thread.start()     for thread in threads:         thread.join()

然后我们创建 Dockerfile 来打包它：

FROM python:3.9-slim WORKDIR /app COPY multi_ports.py . CMD ["python", "multi_ports.py"]

之后，我们构建它并将其推送到一个容器注册表，稍后我们可以从集群中拉取它——在这个示例中是一个公共的 AWS ECR：

docker buildx build --platform linux/amd64,linux/arm64 -t public.ecr.aws/t1i1g9m6/multi-port-app:latest --push .

然后我们创建部署清单并仅指定端口 8080：

apiVersion: apps/v1 kind:Deployment metadata: name:multi-port-app spec: replicas:1 selector:     matchLabels:       app:multi-port-app template:     metadata:       labels:         app:multi-port-app     spec:       containers:       -name:multi-port-app         image:public.ecr.aws/t1i1g9m6/multi-port-app         ports:         -containerPort:8080 --- apiVersion:v1 kind:Service metadata: name:multi-port-app-service spec: selector:     app:multi-port-app ports:     -protocol:TCP       port:8080       targetPort:8080

最后我们部署它：

kubectl apply -f kubernetes-ports-exposure/multi_ports_dep_svc.yaml

一旦 Pod 启动并运行，我们可以通过运行一个 curler Pod 来检查端口：

kubectl run curler-pod --image=curlimages/curl --restart=Never -- sleep infinity

并查看应用程序 Pod 暴露的端口：

kubectl exec -it curler-pod -- curl http://<pod-ip>:<port>

输出：

如你所见，端口 9090 和 5000 也是开放并监听的，尽管我们只在清单中指定了端口 8080。

5 控制端口访问

那么，如果 ports 字段不控制访问，我们如何保护我们的应用程序呢？

这就是 Kubernetes 网络策略的用武之地。

网络策略允许你定义规则，指定哪些 Pod 可以相互通信以及使用哪些端口。它们充当 Pod 的防火墙，为你提供对集群网络流量的细粒度控制。

以下是一个简单的网络策略示例，仅允许对先前应用程序的端口 8080 的传入流量：

apiVersion: networking.k8s.io/v1 kind:NetworkPolicy metadata: name:allow-only-8080 spec: podSelector:     matchLabels:       app:multi-port-app policyTypes: -Ingress ingress: -from:     -podSelector:{}     ports:     -protocol:TCP       port:8080

此策略将允许来自同一命名空间中任何 Pod 的端口 8080 的传入连接，同时阻止对所有其他端口的连接。

6 最佳实践

鉴于这种行为，以下是一些需要牢记的最佳实践：

不要依赖端口规范来确保安全：记住，Pod 规范中的 ports 字段是用于文档和服务发现的，而不是访问控制。

使用网络策略：实施网络策略以明确定义允许的流量。

遵循最小权限原则：只打开应用程序功能所需的端口。

定期审计你的集群：使用工具扫描意外开放的端口或配置错误。

注意你的基础镜像：了解容器镜像中活动的进程和端口。