☰

与服务 kubernetes 相关的所需信息

tag-icon • tag-icon kubernetes
与服务 kubernetes 相关的所需信息

我的问题是，如果客户端（比如说 kubectl）需要访问集群以执行各种获取/删除/编辑操作，它会使用.kube/config文件，并且我们会将 API 端点指定为 DNS 条目。下面显示的是我们的 NLB DNS 条目。

$ cat config |grep 6443
server: https://ac1poc-20210407164708-kube-api-f5082ea18c7584ad.elb.us-east-1.amazonaws.com:6443
  1. 如果 kubelet 需要与 API 端点通信，则其配置文件中也有类似的条目/etc/kubernetes/kubelet
  2. kube-proxy 也是如此。因此，所有这三个外部 API 都在各自的配置文件中配置了网络负载均衡器条目。这意味着，每当它们想要与 API 后端通信时，它们都会将数据包发送到 NLB。

但是我也有这个服务，如下所示。我想问一下这个服务什么时候起作用。哪个 API 使用此服务？

$ kubectl describe svc kubernetes
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.0.1
IPs:               10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         172.36.11.131:6443,172.36.12.131:6443,172.36.13.131:6443
Session Affinity:  None
Events:            <none>

答案1

我的问题是，如果客户端（比如说 kubectl）需要访问集群以执行各种获取/删除/编辑操作

2）如果 kubelet 需要与 API 端点通信

正确，这两个交互解决的是同一个问题：一个过程如何外部的到 kubernetes 集群到达控制平面。可以想象，它将仅限于（例如）用于kubectl操作的企业 VPN，或仅限于工作子网kubelet。

kubelet其实没有需要使用 NLB（即流量通过任何 Nat GW/Internet GW 从 VPC 流出到 NLB 并返回 VPC），将 kubelet 的配置指向该 NLB 的“内部”端是绝对安全且有效的，只要控制平面证书具有足够的主题备用名称条目来满足 TLS 握手。这通常是人们不费心区分这两种情况的原因，但如果您的组织担心安全（或成本！），那么完全可以拆分这两种交互

哪个 API 使用此服务？

CNIService指向同一个控制平面，但流量在集群内传输，并且始终kubernetes.default.svc.cluster.local Service可供所有人使用，并且任何 Pod 内的 kubernetes 客户端都可以通过内置令牌访问 kubernetes API。这样，集群内运行的任何内容都不需要进行任何配置即可访问 API（包括 Internet 访问），因为集群内的流量不会离开 CNI 网络NamespaceServiceAccount

相关内容