concepts/architecture/master-node-communication/
本文件對主伺服器（實際上是apiserver）和kubernetes叢集之間的通訊路徑進行了編目。其目的是允許使用者自定義其安裝以強化網路配置，從而使群集可以在不受信任的網路（或雲提供商上的完全公共IP）上執行。
Cluster to Master
從叢集到主伺服器(master)的所有通訊路徑都終止於apiserver（其他主元件都不設計為公開遠端服務）。在典型的部署中，APIServer配置為在啟用了一種或多種形式的客戶端身份驗證 的安全https埠（443）上偵聽遠端連線。應啟用一種或多種形式的授權，尤其是在允許匿名請求或服務帳戶令牌的情況下。
應為節點設定群集的公用根證照，以便它們可以與有效的客戶端憑據一起安全地連線到APIServer。例如，在預設的gke部署中，提供給kubelet的客戶端憑據是以客戶端證照的形式提供的。參見kubelet tls bootstrapping瞭解kubelet客戶端證照的自動設定。
Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The kubernetes service (in all namespaces) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver.連線到apiserver的pod可以通過利用服務帳戶來安全地連線，這樣kubernetes將在pod被例項化時自動將公共根證照和有效的承載令牌注入到pod中。kubernetes服務（在所有名稱空間中）都配置了一個虛擬IP地址，該地址被重定向（通過kube代理）到APIServer上的https端點。
the master components also communicate with the cluster apiserver over the secure port.主元件(排程器,控制器)還通過安全埠與叢集APIServer通訊。
因此，預設情況下，從叢集（節點及節點執行的pod）到主機的連線的預設操作模式是安全的，並且可以在不受信任和/或公共網路上執行。As a result, the default operating mode for connections from the cluster (nodes and pods running on the nodes) to the master is secured by default and can run over untrusted and/or public networks.
Master to Cluster
There are two primary communication paths from the master (apiserver) to the cluster. The first is from the apiserver to the kubelet process which runs on each node in the cluster. The second is from the apiserver to any node, pod, or service through the apiserver’s proxy functionality.從主伺服器（APIServer）到叢集有兩條主通訊路徑。第一個是從apiserver到kubelet程式，kubelet程式在叢集中的每個節點上執行。第二個是通過apiserver的代理功能從apiserver到任何節點、pod或服務。
apiserver to kubelet
從APIServer到Kubelet的連線用於：
- .獲取pods日誌
kubectl連線到pod裡的容器- 提供Kubelet的埠轉發功能.Providing the kubelet’s port-forwarding functionality.
這些連線在kubelet的https endpoint。預設情況下，APIServer不會驗證kubelet的服務證照，這會使連線受到中間人攻擊，並且不安全在不受信任和/或公共網路上執行。
要驗證此連線，請使用--kubelet-certificate-authority引數在APIServer啟動時提供一個根證照包，用於驗證kubelet的服務證照。
如果不可能，請在apiserver和kubelet之間使用ssh隧道，以避免通過不受信任或公共網路進行連線。
最後，應該啟用kubelet身份驗證和/或授權 來保護kubelet api。
apiserver to nodes, pods, and services
從apiserver到節點、pod或service 的連線預設為純http連線，因此既不經過身份驗證也不加密。它們可以通過在api url中的節點、pod或service名前面加上https:來在安全的https連線上執行，但它們不會驗證https端點提供的證照，也不會提供客戶端憑據，因此在對連線進行加密時，它不會提供任何誠信保證。這些連線目前不安全，無法在不受信任和/或公共網路上執行。
SSH Tunnels
kubernetes支援ssh隧道來保護master->叢集通訊路徑。在這種配置中，apiserver啟動到叢集中每個節點的ssh隧道（連線到監聽埠22的ssh伺服器），並通過隧道傳遞到kubelet、節點、pod或service的所有通訊量。此隧道確保流量不會暴露在節點執行的網路外部。
ssh隧道目前已被棄用，因此除非您知道自己在做什麼，否則不應選擇使用它們。正在設計此通訊通道的替代品。
Kubernetes supports SSH tunnels to protect the Master -> Cluster communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running.
SSH tunnels are currently deprecated so you shouldn’t opt to use them unless you know what you are doing. A replacement for this communication channel is being designed.
本作品採用《CC 協議》，轉載必須註明作者和本文連結