k8s部署到云计算上的优势
-
传统模式： 在k8s外部部署一个外置调度器，请求先到物理node节点ip地址，由物理服务地址再转发代理至service地址，如果node节点也是私网地址呢，就需要再外部部署一个外置的调度器，在这个调度器可以调度至任意节点上，node节点上只能有一个端口来转发到service服务的端口，中间需要经过很多次转发，性能降低很多。外置调度器已经处于k8s外部了，不能通过k8s命令来创建，这时就需要LBaaS云计算上。
-
LBaaS：负载均衡即服务，可以根据命令一次调一个API创建一个负载均衡器，这个负载均衡器可以存着集群外部，如果该负载均衡器是由软件实现的可直接由命令请求创建，因此如果我们将k8s运行在阿里云这样的虚拟机上，多个这样的虚拟机组成k8s集群，阿里云或者亚马逊云是支持LBaaS的，所以k8s可对外调用底层的云计算环境创建一个调度器，将服务接入进来，将k8s部署在云计算上有这个优势。
k8s内部存在三种网络
- pod网络，事实存在的网络能够ping通
- service网络，集群网络，虚拟网络由iptables或者ipvs规则创建的，ping不通
- node节点物理机网络
外部访问先访问到node节点网络，由节点网络代理至集群网络，在由集群网络代理至pod网络。
k8s内部三种通信
-
同一个pod内的多个容器间通信
lo本地通信
-
各pod之间的通信
Overlay Network叠加网络(通过隧道方式来转发二层报文，虽然pod跨主机但是就像在同一主机工作一样)
每个node地址处于不同网段，防止pod地址重复
-
pod与service之间的通信
pod是直接配置service的名称或者地址进行访问的，怎么可达service呢
service地址由iptables创建，每台虚拟机都存在iptables规则，pod直接将请求发给网关，可跟service通信。
每个node节点存在kube-proxy组件，service的创建，API Service通知到kube-proxy，kube-proxy负责在每个node创建iptables规则，每个service的变动也是通过kube-proxy反映到各node的iptables规则上。
k8s内部五套证书
- etcd之间的https证书
- etcd和API Server之间的https通信证书
- API Server与客户端之间的https通信证书
- API Server与node节点的kubelet之间的https通信证书
- API Server与node节点的kube-proxy之间的https通信证书
etcd功能
API Server需要存储很多数据，这些数据是放在各个master的共享存储上的，这个共享存储的db就是etcd。
etcd是键值存储的系统，etcd如果宕机，那么k8s集群将崩溃,所以etcd需要做成高可用.
多个etcd通过https通信,不通过http通信，防止数据被盗走。