K8S基础组件之Master与Node节点服务详解、Service基于iptables与ipvs实现

master运行机制

kube-apiserver

k8s API Server提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。

apiserver 目前在master监听两个端口，通过 --insecure-port int 监听一个非安全的127.0.0.1本地端口(默认为
8080)

该端口用于接收HTTP请求；
该端口默认值为8080，可以通过API Server的启动参数“--insecure-port”的值来修改默认值；
默认的IP地址为“localhost”，可以通过启动参数“--insecure-bind-address”的值来修改该IP地址；
非认证或未授权的HTTP请求通过该端口访问API Server(kube-controller-manager、kube-scheduler)。
通过参数--bind-address=192.168.7.101 监听一个对外访问且安全(https)的端口(默认为6443)：
该端口默认值为6443，可通过启动参数“--secure-port”的值来修改默认值；
默认IP地址为非本地（Non-Localhost）网络端口，通过启动参数“--bind-address”设置该值；
该端口用于接收客户端、dashboard等外部HTTPS请求；
用于基于Tocken文件或客户端证书及HTTP Base的认证；
用于基于策略的授权；

kubernetes API Server的功能与使用：
提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
是资源配额控制的入口；
拥有完备的集群安全机制.

curl 127.0.0.1:8080/apis #分组api
curl 127.0.0.1:8080/api/v1 #带具体版本号的api
curl 127.0.0.1:8080/ #返回核心api列表 
curl 127.0.0.1:8080/version #api 版本信息
curl 127.0.0.1:8080/healthz/etcd #与etcd的心跳监测
curl 127.0.0.1:8080/apis/autoscaling/v1 #api的详细信息
curl 127.0.0.1:8080/metrics #指标数据

kube-controller-manager

Controller Manager作为集群内部的管理控制中心，非安全默认端口10252，负责集群内的Node、Pod副本、服
务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）
的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预
期的工作状态。

kube-scheduler

Scheduler负责Pod调度，在整个系统中起"承上启下"作用，承上：负责接收Controller Manager创建的新的Pod，
为其选择一个合适的Node；启下：Node上的kubelet接管Pod的生命周期。

通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最适合的Node，并将信息写入etcd中
node节点上的kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应的Pod清
单，下载Image，并启动容器。

优选策略
1.LeastRequestedPriority
优先从备选节点列表中选择资源消耗最小的节点（CPU+内存）

2.CalculateNodeLabelPriority
优先选择含有指定Label的节点

3.BalancedResourceAllocation
优先从备选节点列表中选择各项资源使用率最均衡的节点

node节点运行机制

kubelet

在kubernetes集群中，每个Node节点都会启动kubelet进程，用来处理Master节点下发到本节点的任务，管理
Pod和其中的容器。kubelet会在API Server上注册节点信息，定期向Master汇报节点资源使用情况，并通过
cAdvisor(顾问)监控容器和节点资源，可以把kubelet理解成Server/Agent架构中的agent，kubelet是Node上的
pod管家。

kube-proxy

kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化，再通过管理 IPtables 来实现网络的转发。

Kube-Proxy 不同的版本可支持三种工作模式：
[添加链接描述](https://kubernetes.io/zh/docs/concepts/services-networking/service/)

UserSpace
k8s v1.2 及以后就已经淘汰
IPtables
目前默认方式，1.1开始支持，1.2开始为默认
IPVS
1.9引入到1.11正式版本，需要安装ipvsadm、ipset 工具包和加载 ip_vs 内核模块

启动脚本：

]#: cat /etc/systemd/system/kube-proxy.service
[Unit]
Description=Kubernetes Kube-Proxy Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target
[Service]
WorkingDirectory=/var/lib/kube-proxy
ExecStart=/usr/bin/kube-proxy \
--bind-address=192.168.7.111 \
--hostname-override=192.168.7.111 \
--kubeconfig=/etc/kubernetes/kube-proxy.kubeconfig \ #配置文件
--logtostderr=true \
# --proxy-mode=iptables #配置转发模式
--proxy-mode=ipvs
--ipvs-scheduler=sh  # 配置调度算法为源地址哈希，支持rr、lc、dh、sed、nq
Restart=on-failure
RestartSec=5
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target

iptables

Kube-Proxy 监听 Kubernetes Master 增加和删除 Service 以及 Endpoint 的消息。对于每一个 Service，Kube
Proxy 创建相应的 IPtables 规则，并将发送到 Service Cluster IP 的流量转发到 Service 后端提供服务的 Pod 的相
应端口上。
注：
虽然可以通过 Service 的 Cluster IP 和服务端口访问到后端 Pod 提供的服务，但该 Cluster IP 是 Ping 不通的。
其原因是 Cluster IP 只是 IPtables 中的规则，并不对应到一个任何网络设备。
IPVS 模式的 Cluster IP 是可以 Ping 通的。

默认策略是，kube-proxy在iptables模式下随机选择一个backend；
如果kube-proxy在iptables模式下运行，并且所选的第一个pod没有响应，则连接失败，并将流量自动调度到另外的pod重试；
可以使用pod readliness 探测器检测后端pod可以正常工作。

IPVS

kubernetes从1.9开始测试支持ipvs(Graduate kube-proxy IPVS mode to beta)，https://github.com/kubernete
s/kubernetes/blob/master/CHANGELOG-1.9.md#ipvs，从1.11版本正式支持ipvs(IPVS-based in-cluster load
balancing is now GA)，https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#ipvs。

IPVS 相对 IPtables 效率会更高一些，使用 IPVS 模式需要在运行 Kube-Proxy 的节点上安装 ipvsadm、ipset 工具
包和加载 ip_vs 内核模块，当 Kube-Proxy 以 IPVS 代理模式启动时，Kube-Proxy 将验证节点上是否安装了 IPVS
模块，如果未安装，则 Kube-Proxy 将回退到 IPtables 代理模式。

使用IPVS模式，Kube-Proxy会监视Kubernetes Service对象和Endpoints，调用宿主机内核Netlink接口以相应
地创建IPVS规则并定期与Kubernetes Service对象 Endpoints对象同步IPVS规则，以确保IPVS状态与期望一致，
访问服务时，流量将被重定向到其中一个后端 Pod,IPVS使用哈希表作为底层数据结构并在内核空间中工作，这意味着
IPVS可以更快地重定向流量，并且在同步代理规则时具有更好的性能，此外，IPVS 为负载均衡算法提供了更多选项，例
如：rr (轮询调度)、lc (最小连接数)、dh (目标哈希)、sh (源哈希)、sed (最短期望延迟)、nq(不排队调度)
等。