kubernetes如何实现集群各模块之间的通信
这篇文章主要为大家展示了“kubernetes如何实现集群各模块之间的通信”，内容简而易懂，条理清晰，希望能够帮助大家解决疑惑，下面让小编带领大家一起研究并学习一下“kubernetes如何实现集群各模块之间的通信”这篇文章吧。
为怀宁等地区用户提供了全套网页设计制作服务，及怀宁网站建设行业解决方案。主营业务为网站设计制作、成都做网站、怀宁网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
一： 通信结构图
二：kubernetes客户端认证方式
Kubernetes提供管理三种级别的客户端身份认证方式：
1.最严格的HTTPS证书认证：基于CA根证书签名的双向数字证书认证方式；
2.HTTP Token认证：通过一个Token来识别合法用户；
3.HTTP Base认证：通过用户名+密码的方式认证；
上图中展示的是使用HTTPS证书认证的方式。
三：各模块之间的通信方式
在开启了 TLS 的集群中，每当与集群交互的时候少不了的是身份认证，使用 kubeconfig（即证书） 和 token 两种认证方式是最简单也最通用的认证方式。
1.kubectl跟API Server之间采用的是kubeconfig进行TLS的认证
2.kubelet跟API Server之间采用Token(bootstrap token)和Kubeconfig相结合的方式进行TLS的认证
3.Pod跟API Server之间采用的是Token(Service Account Token)的方式进行TLS的认证。
4.集群外用户通过kubectl proxy 方式提供http访问（仅作测试用）
5.scheduler,controller manager与API Server之间通过Http访问（scheduler,controller manager,API Server要求部署在同一台服务器上）
6.ETCD之间通过TLS进行通信
7.API Server与ETCD之间通过TLS进行通信
8.API SERVER与kube-proxy之间通过kubeconfig进行TL的认证
四：kubectl通信设置
kubectl默认会从$HOME/.kube目录下查找文件名为 config 的文件，也可以通过设置环境变量 KUBECONFIG 或者通过设置 --kubeconfig 去指定其它 kubeconfig 文件。
点击(此处)折叠或打开
ETCD_CERT_FILE="/etc/kubernetes/ssl/kubernetes.pem"
ETCD_KEY_FILE="/etc/kubernetes/ssl/kubernetes-key.pem"
ETCD_TRUSTED_CA_FILE="/etc/kubernetes/ssl/ca.pem"
ETCD_PEER_CERT_FILE="/etc/kubernetes/ssl/kubernetes.pem"
ETCD_PEER_KEY_FILE="/etc/kubernetes/ssl/kubernetes-key.pem"
ETCD_PEER_TRUSTED_CA_FILE="/etc/kubernetes/ssl/ca.pem"
--cert-file，--key-file 设置ETCD的公私钥；--peer-cert-file，--peer-key-file设置ETCD集群各节点之间通信的公私钥；--trusted-ca-file=设置客户端CA证书；--peer-trusted-ca-file设置ETCD集群各节点CA证书。
六：API Server与ETCD集群通信设置（apiserver配置文件）
这个是API Server的
CA公钥证书，来源于controller-manager配置文件中的root-ca-file),Namespace名称等三个信息产生一个新的Secret对象，然后放入创建的Service Account中。
2.API Server收到Token以后，采用自己的私钥（实际是使用apiserver配置文件中的参数service-account-key-file指定的私钥，如果此参数没有设置，则默认采用tls-private-key-file指定的参数，即自己的私钥）对Token进行合法验证。
九：API Server与kube-proxy之间通信设置
点击(此处)折叠或打开
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUR2akNDQXFhZ0F3SUJBZ0lVSVprZlNwNSs5REY3OUZEYXFhQ1haYXRsOG9Rd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1pURUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbAphVXBwYm1jeEREQUtCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByCmRXSmxjbTVsZEdWek1CNFhEVEU0TURNeE1qQTFNall3TUZvWERUSXpNRE14TVRBMU1qWXdNRm93WlRFTE1Ba0cKQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbGFVcHBibWN4RERBSwpCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByZFdKbGNtNWxkR1Z6Ck1JSUJJakFOQmdrcWhraUc5dzBCQVFFRkFBT0NBUThBTUlJQkNnS0NBUUVBcERaU3NjQWF2N3Roa0JDUTZYN2cKWGZCZ3JOZWM2amc1YjdzVXEzSENyc1hYL3dlOW5POVNxVmxGdS8vY3VMTXNiWEhTdGhXYzJtTXBhdzlmQWVUdwpqK2gyOVZjTkJEamhWbzNhbUFZNk9pR1hOWWZQd0hsaHN4bVFXT0Zrc1NybnpOaGk4djc5K0R5bk1Bc3BSVHlxCk5KODdSUi93d0x6TDVUcFlka1U2U3dIK1ZsR01NRjNEMFdRSjV1ZHlNbFBiRnQyWVVnZE1VRXVCdDRVYWp3d2cKZE9jSVdEcFV0Q0pGNXUvU3RTaHA3RDdRb05rUDdKa2dodm5KMEx6enZxZnlkVFE2MW1HSXIvUHpYS0d3VkJoTgpEQ0hCMTJ1SDBEUkxwK3V2UE5pdmRYcS9wSzE0dWlxYjFoTGdRbzd6OS92d0xBMVg0c0FrU1o2UjUzQzBEZ3kvCnN3SURBUUFCbzJZd1pEQU9CZ05WSFE4QkFmOEVCQU1DQVFZd0VnWURWUjBUQVFIL0JBZ3dCZ0VCL3dJQkFqQWQKQmdOVkhRNEVGZ1FVbG00R3RSbFgzZmYrWkFjLzI1cmdURHNhTEo0d0h4WURWUjBqQkJnd0ZvQVVsbTRHdFJsWAozZmYrWkFjLzI1cmdURHNhTEo0d0RRWUpLb1pJaHZjTkFRRUxCUUFEZ2dFQkFISWVvY1lXM21ZVVdMbTVkR3hvCnN0a01DZlc3aDhDMEduZ2ZIOXFhbFZVTzk0b0RDd2hEMWlqOWtZVW9nZzF3a1BFbGZjSWEybERDOFZBckJtZ3UKWXhFOEJwSkpxMUtIaXAyM0xXSXhWTFB4VWs5ckFUNEtwbE9idmo1RG5adTFDTndlVXJpWU1QUEtRc01LaXROaApVQ3pBV0FVTUpIa2JwVHdsZGNBYmtGMHFyUThGRzZsa1EwakRpTUpKc0ZrelEzbU5YY1pzYXpnamNRWjJHczBxCkhySzlrQ2FHTWtHbzEvQUtDYms5VzZEZDBpL05QeWtvT2d3U1ExMzFSaHQrYmlGZVdVOWQwYjZST3JyYW9GeFoKd1hnZGRYZm11UHQ3eHhyeVFZTUN0NWxRYkQ4aS8wNzJZMGVNYVpQU09jc2xtTk1RQWpsN3Z6T0N0UGcyRzNKNAoxemM9Ci0tLS0tRU5EIENFUlRJRklDQVRFLS0tLS0K
server: https://-----------------
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: kube-proxy
name: default
current-context: default
kind: Config
preferences: {}
users:
- name: kube-proxy
user:
as-user-extra: {}
client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUQzakNDQXNhZ0F3SUJBZ0lVTCtlZWYzVmJjenZiZFBueUxCdXlMTmJlWFVNd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1pURUxNQWtHQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbAphVXBwYm1jeEREQUtCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUk13RVFZRFZRUURFd3ByCmRXSmxjbTVsZEdWek1CNFhEVEU0TURNeE1qQTJOVEl3TUZvWERUSTRNRE13T1RBMk5USXdNRm93YkRFTE1Ba0cKQTFVRUJoTUNRMDR4RURBT0JnTlZCQWdUQjBKbGFVcHBibWN4RURBT0JnTlZCQWNUQjBKbGFVcHBibWN4RERBSwpCZ05WQkFvVEEyczRjekVQTUEwR0ExVUVDeE1HVTNsemRHVnRNUm93R0FZRFZRUURFeEZ6ZVhOMFpXMDZhM1ZpClpTMXdjbTk0ZVRDQ0FTSXdEUVlKS29aSWh3Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBTHo5bzVJTk5jMWgKU1NSeEs5SU5TcmhPZm4wcHV4dlF0cUp2Yzl0UFNUVXQ3QkZLT1h7dXd2VkowY1hKV201M2xZTEtObm9oSnljdgpsTElZSUhBMXFDa1hOTnNrc2huRlJPYmNmTFZMWU50cXV6WDBoQm5vaUtPYU8vYzUrVEpIYW41a1R3YXhSNklNCmZNNitlZkxTYUU0VGUzenRwVHVMVjlUT2QyZEdJTHpJRm1BSDFmZW5VNnJvUEsxcEtHbjZjUmlKZXk5S1VSNzIKWHpsZXZONWplTCs5cXNWSitINVo3ZFdrd21iQ2VqdWxYNVpZUmxZYm5sdSsxZ2syRXN0Z0NEODUrdldvYklHVgpJTkZmS2Q2YW1jN0E2cnVhQTh5aW54RTNtOFpuQmQzaFMyNktZSUlQVUExTGxNb05KTHBUK0Z4ZlA2MFN2bXBIClZWQktXSURUSDlVQ0F3RUFBYU4vTUgwd0RnWURWUjBQQVFIL0JBUURBZ1dnTUIwR0ExVWRKUVFXTUJRR0NDc0cKQVFVRkJ3TUJCZ2dyQmdFRkJRY0RBakFNQmdOVkhSTUJBZjhFQWpBQU1CMEdBMVVkRGdRV0JCUWR5M0pidTVYNQoxbE9PcTFWRzZRbDBuM1JxblRBZkJnTlZIU01FR0RBV2dCU1diZ2ExR1ZmZDkvNWtCei9ibXVCTU94b3NuakFOCkJna3Foa2lHOXcwQkFRc0ZBQU9DQVFFQVcxWWNhdGlTVS9XVFZzc2R2dVNwdGpUQllleGhrZlhSMjNIU3VnYUIKM1J4T2JscG5ETEtWdVVxY2dZMnIrTEU2SEFKZG9scEVydlc0RDRISFgzbW8wVTdFdlZVNUlvU1JmQ2p4dTZmaApDK0VsbzcybmFPNW96Y2NVbXcwaisrKzN6UzFZTnE0LzF0ZzhTd1NBOWx0alI5SU9kOHY4ZS91UWJnN2ZuMHJnCmxsR28rb0dxa0JaSDlnQzROc0Frd1haYUJPWWxjcDJEN244S2dqRS9DaWsxWDZzSDJiL0tPb1ZHR3NiTDRwY1QKMUxlOFFROWk4dDRlclI3OFlFVFFwZnJVbkZjUndlZTkvbDJSeVBDRDROSVpiZ0U5UXVCWW9nMUc3bjNYWG9DNwpFNUtWdUFXRkJraFBEaG44MU9RczRkamtBWkFIaEF1c1ZSUTByTzlPeVpodG53PT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo=
以上是“kubernetes如何实现集群各模块之间的通信”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注创新互联行业资讯频道！
新闻标题：kubernetes如何实现集群各模块之间的通信
URL地址：http://6mz.cn/article/pocpod.html