kubeedge 这个边缘计算平台有一个特点：它的边缘节点网络和云端节点的网络不是在一个平面的，边缘的计算节点通过加入边缘集群的时候，并不要求自身的IP从云端可达，这是很符合真实场景的。
- kubelet 上报的kubelet server 信息
它是kubelet 上报的信息， 看到的重要信息如下：在边缘计算节点加入集群后，cloudcore 生成的 node 中包含了该edge node 的 KubeletEndpoint 端口和它的IP 以及主机名（也就是 看到的node 名称）。
- 的实现原理（how kubectl logs works）
发起一个日志查询请求，打开详细日志：可以看到，kubectl 其实是发起了2个请求：
- 查询该pod，主要是确认pod是否存在，以及是否存在多个容器
- 拼接出来 并向真正的该pod 所在的node kubelet server 发起请求
我们从kubeapiserver 的相关代码就可以看出来，具体的解释在下边代码中做了编辑：
接下来我们看下
这里会从Node Status的address 中选一个地址做url的host，一般是InternalIP，显然是一个内网IP，当这个IP 从云端可达的时候，我们去执行 或者 的时候会用这个IP 和 kubeletEndpoint（默认是10250） 拼接出目的kubelet server 的地址。
但是当Pod 运行在Edge Node 上时，这个IP是不可达的，那么kubeedge 是怎么做的呢？前戏很长，但是很有必要，让我们开启今天的正题。
可以看到apiserver 通过 tunnelserver与的node 的ws通道发给node上的kubelet server，我们分了10步去解释整个过程，接下来一步步的从代码去深入分析。
这里启动
它会把hostname 和 internalIP 做key，session 做value。
这样，我们就可以在stream server 的处理中，获取到根据request 的host获取到session，并且获取到该wss connection
前言背景中，提到了API Server 会对host:10350 发起请求
解释在code里。
这一步，写回tunnel
代码中做了解释。
到此这篇kubectl 证书（kubectl证书验证）的文章就介绍到这了,更多相关内容请继续浏览下面的相关推荐文章，希望大家都能在编程的领域有一番成就！版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/cjjbc/19583.html