测验：Service 与网络

有 NodePort 服务：port: 80、targetPort: 8080和nodePort: 30080。每个端口的正确含义是什么？

• Pod 上的所有三个端口都必须打开
• 客户端连接到 ClusterIP 80 或节点 30080，流量路由到 pod 8080。
• nodePort 是容器端口，targetPort 是节点端口。
• 客户端附加到节点上的8080，pod监听80，30080是ClusterIP端口。

我把ports: [{containerPort: 8080, name: api}]给了容器，并在Service中指定为targetPort: api。这样的配置有什么优点呢？

• 如果使用 targetPort 作为名称，它将直接连接，而无需通过 kube-proxy。
• 该服务自动变为无头并将 Pod IP 返回给 DNS。
• 即使每个 Pod 的实际端口号不同，服务也可以按原样使用，无需修改。
• 唯一的影响是端口名称作为 DNS SRV 记录公开，以便客户端可以查找端口。

无头服务cache-hs和 StatefulSetcache（副本 3）是在命名空间ckad-net中创建的。第一个 Pod 的完全限定 DNS 名称是什么？

• cache-0.ckad-net.cache-hs.svc.cluster.local
• cache-0.cache-hs.svc.ckad-net.cluster.local
• cache-hs.cache-0.ckad-net.svc.cluster.local
• cache-0.cache-hs.ckad-net.svc.cluster.local

kubectl get endpoints backend的结果是<none>。最可能的原因是什么？

• 由于服务类型为ClusterIP，因此未创建端点。
• 由于网络策略，端点注册被阻止。
• 这是因为 targetPort 被指定为名称。
• 服务选择器与 Pod 标签不匹配，或者 Pod 未处于就绪状态。

path: /api和pathType: Prefix被赋予 Ingress 规则。哪个请求匹配？

• /api和/api/users匹配，但/apixyz不匹配。
• 它被解释为正则表达式，/a和/ap也匹配。
• 仅/api匹配
• /api、/api/users和/apixyz均匹配。

应用了仅为podSelector: {app: backend}和policyTypes: [Ingress]指定的 NetworkPolicy。后端 pod 的正确行为是什么？

• DNS（端口 53）始终自动允许，因此无需单独的规则。
• 仅允许规则中指定的传入流量，不限制传出流量。
• 所有传入和传出流量均已列入白名单。
• 即使应用了该策略，除非其他 Pod 也具有该策略，否则它不会产生任何效果。