這篇文章主要為大家展示了“kubernetes如何實(shí)現(xiàn)集群各模塊之間的通信”，內(nèi)容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“kubernetes如何實(shí)現(xiàn)集群各模塊之間的通信”這篇文章吧。

成都創(chuàng)新互聯(lián)網(wǎng)站建設(shè)公司是一家服務(wù)多年做網(wǎng)站建設(shè)策劃設(shè)計(jì)制作的公司,為廣大用戶提供了網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè)，成都網(wǎng)站設(shè)計(jì)，廣告投放平臺(tái)，成都做網(wǎng)站選成都創(chuàng)新互聯(lián)，貼合企業(yè)需求，高性價(jià)比，滿足客戶不同層次的需求一站式服務(wù)歡迎致電。

一： 通信結(jié)構(gòu)圖

二：kubernetes客戶端認(rèn)證方式
Kubernetes提供管理三種級(jí)別的客戶端身份認(rèn)證方式：
1.最嚴(yán)格的HTTPS證書認(rèn)證：基于CA根證書簽名的雙向數(shù)字證書認(rèn)證方式；
2.HTTP Token認(rèn)證：通過一個(gè)Token來識(shí)別合法用戶；
3.HTTP Base認(rèn)證：通過用戶名+密碼的方式認(rèn)證；

上圖中展示的是使用HTTPS證書認(rèn)證的方式。
三：各模塊之間的通信方式
在開啟了 TLS 的集群中，每當(dāng)與集群交互的時(shí)候少不了的是身份認(rèn)證，使用 kubeconfig（即證書） 和 token 兩種認(rèn)證方式是最簡單也最通用的認(rèn)證方式。

1.kubectl跟API Server之間采用的是kubeconfig進(jìn)行TLS的認(rèn)證
2.kubelet跟API Server之間采用Token(bootstrap token)和Kubeconfig相結(jié)合的方式進(jìn)行TLS的認(rèn)證
3.Pod跟API Server之間采用的是Token(Service Account Token)的方式進(jìn)行TLS的認(rèn)證。
4.集群外用戶通過kubectl proxy 方式提供http訪問（僅作測試用）
5.scheduler,controller manager與API Server之間通過Http訪問（scheduler,controller manager,API Server要求部署在同一臺(tái)服務(wù)器上）
6.ETCD之間通過TLS進(jìn)行通信
7.API Server與ETCD之間通過TLS進(jìn)行通信
8.API SERVER與kube-proxy之間通過kubeconfig進(jìn)行TL的認(rèn)證

四：kubectl通信設(shè)置

kubectl默認(rèn)會(huì)從$HOME/.kube目錄下查找文件名為 config 的文件，也可以通過設(shè)置環(huán)境變量 KUBECONFIG 或者通過設(shè)置 --kubeconfig 去指定其它 kubeconfig 文件。

點(diǎn)擊(此處)折疊或打開

1. ETCD_CERT_FILE="/etc/kubernetes/ssl/kubernetes.pem"

2. ETCD_KEY_FILE="/etc/kubernetes/ssl/kubernetes-key.pem"

3. ETCD_TRUSTED_CA_FILE="/etc/kubernetes/ssl/ca.pem"

4. ETCD_PEER_CERT_FILE="/etc/kubernetes/ssl/kubernetes.pem"

5. ETCD_PEER_KEY_FILE="/etc/kubernetes/ssl/kubernetes-key.pem"

6. ETCD_PEER_TRUSTED_CA_FILE="/etc/kubernetes/ssl/ca.pem"

--cert-file，--key-file 設(shè)置ETCD的公私鑰；--peer-cert-file，--peer-key-file設(shè)置ETCD集群各節(jié)點(diǎn)之間通信的公私鑰；--trusted-ca-file=設(shè)置客戶端CA證書；--peer-trusted-ca-file設(shè)置ETCD集群各節(jié)點(diǎn)CA證書。

六：API Server與ETCD集群通信設(shè)置（apiserver配置文件）

這個(gè)是API Server的

CA公鑰證書，來源于controller-manager配置文件中的root-ca-file),Namespace名稱等三個(gè)信息產(chǎn)生一個(gè)新的Secret對象，然后放入創(chuàng)建的Service Account中。

2.API Server收到Token以后，采用自己的私鑰（實(shí)際是使用apiserver配置文件中的參數(shù)service-account-key-file指定的私鑰，如果此參數(shù)沒有設(shè)置，則默認(rèn)采用tls-private-key-file指定的參數(shù)，即自己的私鑰）對Token進(jìn)行合法驗(yàn)證。
九：API Server與kube-proxy之間通信設(shè)置

點(diǎn)擊(此處)折疊或打開

1. apiVersion: v1

2. clusters:

3. - cluster:

4.     certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVSVprZlNwNSs5REY3OUZEYXFhQ1haYXRsOG9Rd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1pURUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbAphVXBwYm1jeEREQUtCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByCmRXSmxjbTVsZEdWek1CNFhEVEU0TURNeE1qQTFNall3TUZvWERUSXpNRE14TVRBMU1qWXdNRm93WlRFTE1Ba0cKQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbGFVcHBibWN4RERBSwpCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByZFdKbGNtNWxkR1Z6Ck1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBcERaU3NjQWF2N3Roa0JDUTZYN2cKWGZCZ3JOZWM2amc1YjdzVXEzSENyc1hYL3dlOW5POVNxVmxGdS8vY3VMTXNiWEhTdGhXYzJtTXBhdzlmQWVUdwpqK2gyOVZjTkJEamhWbzNhbUFZNk9pR1hOWWZQd0hsaHN4bVFXT0Zrc1NybnpOaGk4djc5K0R5bk1Bc3BSVHlxCk5KODdSUi93d0x6TDVUcFlka1U2U3dIK1ZsR01NRjNEMFdRSjV1ZHlNbFBiRnQyWVVnZE1VRXVCdDRVYWp3d2cKZE9jSVdEcFV0Q0pGNXUvU3RTaHA3RDdRb05rUDdKa2dodm5KMEx6enZxZnlkVFE2MW1HSXIvUHpYS0d3VkJoTgpEQ0hCMTJ1SDBEUkxwK3V2UE5pdmRYcS9wSzE0dWlxYjFoTGdRbzd6OS92d0xBMVg0c0FrU1o2UjUzQzBEZ3kvCnN3SURBUUFCbzJZd1pEQU9CZ05WSFE4QkFmOEVCQU1DQVFZd0VnWURWUjBUQVFIL0JBZ3dCZ0VCL3dJQkFqQWQKQmdOVkhRNEVGZ1FVbG00R3RSbFgzZmYrWkFjLzI1cmdURHNhTEo0d0h4WURWUjBqQkJnd0ZvQVVsbTRHdFJsWAozZmYrWkFjLzI1cmdURHNhTEo0d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFISWVvY1lXM21ZVVdMbTVkR3hvCnN0a01DZlc3aDhDMEduZ2ZIOXFhbFZVTzk0b0RDd2hEMWlqOWtZVW9nZzF3a1BFbGZjSWEybERDOFZBckJtZ3UKWXhFOEJwSkpxMUtIaXAyM0xXSXhWTFB4VWs5ckFUNEtwbE9idmo1RG5adTFDTndlVXJpWU1QUEtRc01LaXROaApVQ3pBV0FVTUpIa2JwVHdsZGNBYmtGMHFyUThGRzZsa1EwakRpTUpKc0ZrelEzbU5YY1pzYXpnamNRWjJHczBxCkhySzlrQ2FHTWtHbzEvQUtDYms5VzZEZDBpL05QeWtvT2d3U1ExMzFSaHQrYmlGZVdVOWQwYjZST3JyYW9GeFoKd1hnZGRYZm11UHQ3eHhyeVFZTUN0NWxRYkQ4aS8wNzJZMGVNYVpQU09jc2xtTk1RQWpsN3Z6T0N0UGcyRzNKNAoxemM9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K

5.     server: https://-----------------

6.   name: kubernetes

7. contexts:

8. - context:

9.     cluster: kubernetes

10.     user: kube-proxy

11.   name: default

12. current-context: default

13. kind: Config

14. preferences: {}

15. users:

16. - name: kube-proxy

17.   user:

18.     as-user-extra: {}

19.     client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQzakNDQXNhZ0F3SUJBZ0lVTCtlZWYzVmJjenZiZFBueUxCdXlMTmJlWFVNd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1pURUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbAphVXBwYm1jeEREQUtCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByCmRXSmxjbTVsZEdWek1CNFhEVEU0TURNeE1qQTJOVEl3TUZvWERUSTRNRE13T1RBMk5USXdNRm93YkRFTE1Ba0cKQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbGFVcHBibWN4RERBSwpCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUm93R0FZRFZRUURFeEZ6ZVhOMFpXMDZhM1ZpClpTMXdjbTk0ZVRDQ0FTSXdEUVlKS29aSWh3Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTHo5bzVJTk5jMWgKU1NSeEs5SU5TcmhPZm4wcHV4dlF0cUp2Yzl0UFNUVXQ3QkZLT1h7dXd2VkowY1hKV201M2xZTEtObm9oSnljdgpsTElZSUhBMXFDa1hOTnNrc2huRlJPYmNmTFZMWU50cXV6WDBoQm5vaUtPYU8vYzUrVEpIYW41a1R3YXhSNklNCmZNNitlZkxTYUU0VGUzenRwVHVMVjlUT2QyZEdJTHpJRm1BSDFmZW5VNnJvUEsxcEtHbjZjUmlKZXk5S1VSNzIKWHpsZXZONWplTCs5cXNWSitINVo3ZFdrd21iQ2VqdWxYNVpZUmxZYm5sdSsxZ2syRXN0Z0NEODUrdldvYklHVgpJTkZmS2Q2YW1jN0E2cnVhQTh5aW54RTNtOFpuQmQzaFMyNktZSUlQVUExTGxNb05KTHBUK0Z4ZlA2MFN2bXBIClZWQktXSURUSDlVQ0F3RUFBYU4vTUgwd0RnWURWUjBQQVFIL0JBUURBZ1dnTUIwR0ExVWRKUVFXTUJRR0NDc0cKQVFVRkJ3TUJCZ2dyQmdFRkJRY0RBakFNQmdOVkhSTUJBZjhFQWpBQU1CMEdBMVVkRGdRV0JCUWR5M0pidTVYNQoxbE9PcTFWRzZRbDBuM1JxblRBZkJnTlZIU01FR0RBV2dCU1diZ2ExR1ZmZDkvNWtCei9ibXVCTU94b3NuakFOCkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQVcxWWNhdGlTVS9XVFZzc2R2dVNwdGpUQllleGhrZlhSMjNIU3VnYUIKM1J4T2JscG5ETEtWdVVxY2dZMnIrTEU2SEFKZG9scEVydlc0RDRISFgzbW8wVTdFdlZVNUlvU1JmQ2p4dTZmaApDK0VsbzcybmFPNW96Y2NVbXcwaisrKzN6UzFZTnE0LzF0ZzhTd1NBOWx0alI5SU9kOHY4ZS91UWJnN2ZuMHJnCmxsR28rb0dxa0JaSDlnQzROc0Frd1haYUJPWWxjcDJEN244S2dqRS9DaWsxWDZzSDJiL0tPb1ZHR3NiTDRwY1QKMUxlOFFROWk4dDRlclI3OFlFVFFwZnJVbkZjUndlZTkvbDJSeVBDRDROSVpiZ0U5UXVCWW9nMUc3bjNYWG9DNwpFNUtWdUFXRkJraFBEaG44MU9RczRkamtBWkFIaEF1c1ZSUTByTzlPeVpodG53PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=

以上是“kubernetes如何實(shí)現(xiàn)集群各模塊之間的通信”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)-成都網(wǎng)站建設(shè)公司行業(yè)資訊頻道！

當(dāng)前標(biāo)題：kubernetes如何實(shí)現(xiàn)集群各模塊之間的通信-創(chuàng)新互聯(lián)
本文URL：http://weahome.cn/article/idpph.html