局域网内部网站建设app商品推广软文写作500字
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 threadingclass 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-slimWORKDIR /appCOPY 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-appspec:containers:-name:multi-port-appimage:public.ecr.aws/t1i1g9m6/multi-port-appports:-containerPort:8080
---
apiVersion:v1
kind:Service
metadata:
name:multi-port-app-service
spec:
selector:app:multi-port-app
ports:-protocol:TCPport:8080targetPort: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:TCPport:8080
此策略将允许来自同一命名空间中任何 Pod 的端口 8080 的传入连接，同时阻止对所有其他端口的连接。
6 最佳实践
鉴于这种行为，以下是一些需要牢记的最佳实践：
-
不要依赖端口规范来确保安全：记住，Pod 规范中的
ports字段是用于文档和服务发现的，而不是访问控制。 -
使用网络策略：实施网络策略以明确定义允许的流量。
-
遵循最小权限原则：只打开应用程序功能所需的端口。
-
定期审计你的集群：使用工具扫描意外开放的端口或配置错误。
-
注意你的基础镜像：了解容器镜像中活动的进程和端口。