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://cdiso.cn/article/idpph.html