K8S 组件介绍 文档 ： http://docs.kubernetes.org.cn/230.html
Kube-apiserver
kube-apiserver用于暴露Kubernetes API。任何的资源请求/调用操作都是通过kube-apiserver提供的接口进行，是整个系统的数据总线和数据中心
apiserver 目前在master监听两个端口
通过参数 --insecure-port 8080 监听一个非安全的127.0.0.1本地端口(默认为8080)
通过参数 --bind-address=10.0.0.3 监听一个对外访问且安全(https)的端口(默认为6443)
curl 127.0.0.1:8080/ #查看所有api
Kube-scheduler
kube-scheduler是 Kubernetes集群的pod调度器，是一个拥有丰富策略、能够感知拓扑变化、支持特定负载的功能组件，调度器显著影响可用性、性能
通过调度算法为待调度的Pod从可用Node列表中选择一个最适合Node，并将信息写入etcd中
Kube-controller-manager
kube-controller-manager作为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额(ResourceQuota)的管理，每个Controller通过API Server提供的接口实时监控整个集群的每个资源对象状态,当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态
Kubelet
在kubernetes集群中，每个Node节点都会启动kubelet进程，用来处理Master节点下发到本节点的任务，管理Pod和其中的容器。它会监视已分配给节点的pod，向master汇报node节点的状态信息，接受指令并在Pod中创建docker容器，返回pod的运行状态，在node节点执行容器健康检查
Etcd
etcd 是Kubernetes默认使用的key-value数据存储系统，用于保存所有集群数据，包括k8s集群的配置信息和各种资源的状态信息
export ETCDCTL_API=3
etcdctl --help
etcdctl member list #查看etcd成员信息
etcdctl get / --prefix --keys-only #查看etcd数据信息
etcdctl put /yunge "18" #添加数据
etcdctl get /yunge#获取时间
etcdctl del /yunge #删除数据
etcd数据watch机制
基于不断监看数据，发生变化就主动触发通知客户端，Etcd v3 的watch机制支持watch某个固定的key，也支持watch一个范围。
etcdctl watch /yunge
etcdctl put /yunge "18" #另一个终端执行，watch终端会接收
etcd数据备份与恢复机制
etcdctl snapshot save etcd.db #备份数据
etcdctl snapshot restore etcd.db --data-dir=/opt/etcd #数据恢复到新目录
Kubernetes网络代理运行在 node上，kube-proxy它是实现K8S Service的通信与负载均衡机制的重要组件，从apiserver获取信息并创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。其实就是kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务访问
Kube-Proxy
Kube-Proxy工作模式
iptables
Kube-Proxy 监听Kubernetes Master增加和删除Service消息。对于每一个Service，Kube Proxy 创建相应的IPtables规则，并将发送到Service Cluster IP的流量转发到后端提供服务的Pod的相应端口上
虽然可以通过Service的ClusterIP和服务端口访问到后端Pod提供的服务，但该Cluster IP Ping不通。其原因是 Cluster IP 只是 IPtables 中的规则，并不对应到一个任何网络设备
ipvs
IPVS 模式的Cluster IP是可以Ping通的
在大规模集群中，推荐使用性能更好的IPVS，基于IPVS的kube-proxy具有更复杂的负载平衡算法（最小连接，局部性，加权，持久性）
--proxy-mode=iptables #IPtables是默认转发模式，建议修改为IPVS
systemctl daemon-reload
systemctl restart kube-proxy
reboot
ipvsadm -Ln #重启查看IPvs规则
网络组件
k8s中的网络主要涉及到pod的的各种访问需求
k8s的网络基于第三方插件实现，但是定义了一些插件兼容规范，该规范由CoreOS和Google定制的CNI(Container Network Interface)，凡是遵循CNI标准的网络插件都可以在K8S中使用。目前常用的的CNI网络插件有flannel和calico
Flannel
由CoreOS开源的针对k8s的网络服务，其目的为解决k8s集群中各主机上的pod相互通信的问题，其借助etcd维护网络IP地址分配，并为每一个node服务器分配一个不同的IP地址段
UDP：早期版本的Flannel使用UDP封装完成报文的跨越主机转发，其安全性及性能略有不足
VXLAN：Linux 内核在2012年底的v3.7.0之后加入了VXLAN协议支持，VXLAN本质上是一种tunnel(隧道)协议，vxlan是overlay中的一种隧道封装技术，实际上是将数据链路层的以太网帧封装成传输层的UDP数据报文，然后在网络层传输，最终实现的效果类似于在数据链路层的报文传输
Host-gw：也就是Host GateWay，通过在node节点上创建到达各目标容器地址的路由表而完成报文的转发，因此这种方式要求各node节点本身必须处于同一个局域网(二层网络)中，因此不适用于网络变动频繁或比较大型的网络环境，但是其性能较好，和calico不开启IPIP网络类似
Cni0:网桥设备，每创建一个pod都会创建一对veth pair，其中一端是pod中的eth0，另一端是Cni0网桥中的端口（网卡），Pod中从网卡eth0发出的流量都会发送到Cni0网桥设备的端口（网卡）上，Cni0设备获得的ip地址是该节点分配到的网段的第一个地址
Flannel不同node上的pod的通信流程
Flannel.1 是一个overlay网络设备，用来进行vxlan报文的处理(封包和解包)，不同node之间的pod数据流量都从overlay设备以隧道的形式发送到对端，flannel在进行路由转发的基础上进行了封装和解包的操作
Calico
Calico是一个纯三层的网络解决方案，为容器提供多node间的访问通信，calico将每一个node节点都当做为一个路由器，各节点通过BGP(Border Gateway Protocol) 边界网关协议学习并在node节点生成路由规则，从而将不同node节点上的pod连接起来进行通信
calico
node节点所连接的物理交换机需支持BGP协议，许多公有云无法支持BGP协议，所以公有云环境使用flannel
在自建IDC或服务器托管的场合，可以使用calico，提前做好k8s网络规划、子网划分
BGP是一个去中心化的协议，它通过自动学习和维护路由表实现网络的可用性，但是并不是所有的网络都支持BGP，calico 还支持IP-in-IP的叠加模型，简称IPIP，IPIP可以实现跨不同网段建立路由通信，但是会存在安全性问题，其在内核内置，可以通过Calico的配置文件设置是否启用IPIP
IPIP是一种将各Node的路由之间做一个tunnel，再把两个网络连接起来的模式。启用IPIP模式时，Calico将在各Node上创建一个名为"tunl0"的虚拟网络接口，建议关闭IPIP
BGP模式则直接使用物理机作为虚拟路由路（vRouter），不再创建额外的tunnel
两者大致区别：
与Flannel不同，Calico不使用overlay网络。相反，Calico配置第3层网络，该网络使用BGP路由协议在主机之间路由数据包。这意味着在主机之间移动时，不需要将数据包进行额外的封装和解包操作，所以性能会相对高一些
calicoctl node status #验证当前路由表
