二 kubernetes基础

2.1kubernetes简介

• kubernetes最初源于Google内部的Borg，Borg是Google内部的大规模集群管理系统，负责对Google内部很多核心服务的调度和管理，Borg的目的是让用户能够不必操心资源管理的问题，让他们专注于自己的核心业务，并且做到跨多个数据中心的资源利用率最大化。
• Brog主要由BrogMaster、Borglet、Borgcfg和Scheduler组成。
• https://kubernetes.io/zh/ #官网
• https://github.com/kubernetes/kubernetes #github

2.2 kubernetes 架构图

2.3 kubernetes 组件

2.3.1 kube-apiserver

• https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/
• kubernetes API server提供了k8s各类资源对象的增删改查及watch等HTTP Rest接口，这些对象包括 pods、services、replicationcontrollers 等。 API 服务器为 REST 操作提供服务，并为集群的共享状态提供前端， 所有其他组件都通过该前端进行交互。
  • RESTful API：是REST风格的网络接口，REST描述的是在网络中client和server的一种交互形式。
  • REST：是一种软件架构风格，或者说是一种规范，其强调HTTP应当以资源为中学，并且规范了URI的风格，规范了HTTP请求动作(GET/PUT/POST/DELETE/HEAD/OPTIONS)的使用，具有对应得语义。
• kubernetes API server提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
  • 身份认证 token
  • 验证权限
  • 验证指令
  • 执行操作
  • 返回结果
• 默认端口6443，可通过启动参数“--secure-port”来修改默认值。该端口用于接收客户端、dashboard等外部HTTPS请求。
• 默认IP地址为非本地(Non-Localhost)网络端口，通过启动参数“--bind-address”来修该。
• 用于基于Tocken文件或客户端证书及HTTP Base的认证。
• 用于基于策略的授权。

2.3.2 kube-scheduler

2.3.2.1 kube-scheduler简介

• https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-scheduler/
• Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。 在同一个集群中可以使用多个不同的调度器；
• 通过调度算法为待调度Pod列表的每个Pod从可用Node列表中选择一个最合适的Node，并将信息写入到etcd中；
• Node节点上对应得kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应得Pod清单，下载Image，并启动容器。

2.3.2.2 调度策略

• LeastRequestedPriority(默认)
  • 优先从备选节点列表中选择资源消耗最小的节点(CPU+内存)。
• CalculateNodeLabelPriority
  • 优先选择含有指定Lable的节点。
• BalancedResourceAllocation
  • 优先从备选节点列表选择各项资源使用率最均衡的节点。

2.3.2.3 调度过程

1. 创建pod；
2. 过滤掉资源不足的节点；
3. 在剩余可用节点进行删选；
4. 选中节点；

2.3.3 kube-controller-manager

2.3.3.1 kube-controller-manager简介

• https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-controller-manager/
• Controller Manager包括一些子控制器(副本控制器、节点控制器、命名空间控制器和账号控制器等)，控制器作为集群内部的管理控制中心，负责集群内部的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)，服务账号(ServiceAccount)、资源定额(ResourceQuota)的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群中的Pod副本始终处于预期的工作状态。

2.3.3.2 kube-controller-manager维护pod为期望状态

1. controller-manager控制器每间隔5秒检查一次node节点状态；
2. 如果controller-manager控制器没有收到来自node节点的心跳，则将该node节点被标识为不可达；
3. controller-manager将在标记为无法访问之前等待40秒；
4. 如果该node节点被标记为无法访问后5分钟还没有恢复，controller-manager会删除当前node节点的所有pod并在其它可用节点重建这些pod。

2.3.3.3 pod高可用机制

1. node monitor preiod：节点监视周期，每隔5秒一次。
2. node monitor grace period：节点监视宽限期默认40秒。
3. pod eviction timeout：pod驱逐超时时间默认5分钟。

2.3.4 kube-proxy

2.3.4.1 kube-proxy简介

• https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-proxy/
• kuberbetes网络代理运行在node上，它反应了node上kuberbetes API中定义的服务，并通过一组后端进行简单的TCP、UDP和SCTP流转发或者在一组后端进行循环TCP、UDP和SCTP转发，用户必须使用apiserver API创建一个服务来配置代理，其实就是kube-proxy通过在主机上维护网络规划并执行连接转发来实现kuberbetes服务访问。
• kube-proxy运行在每个节点上，监听API Server中服务对象的变化，在通过管理IPtables或者IPVS规则来实现网络转发。

2.3.4.2 kube-proxy工作模式

2.3.4.2.1 kube-proxy工作模式介绍

• UserSpace：k8s v1.1之前使用，k8s v1.2及以后就已经淘汰。
• IPtables：k8s v1.1版本开始支持，v1.2开始默认。
• IPVS: k8s v1.9引入到v1.11为正式版本，需要安装ipvsadm、ipset工具包和加载ip_vs内核模块。IPVS相对于IPtables效率会更高一些，当kube-proxy以IPVS代理模式启动时，kube-proxy将验证节点上是否安装了IPVS模块，如果为安装则kube-proxy将回退到IPtables代理模式。

2.3.4.2.2 IPVS模式

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

2.3.5 kubelet

2.3.5.1 kubelet简介

• https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet/
• kubelet是运行在每个worker节点的代理组件，它会监视已分配给节点的pod。

2.3.5.2 kubelet功能

• 向master汇报node节点的状态信息；
• 接受指令并在Pod中创建docker容器；
• 准备Pod所需的数据卷；
• 返回Pod的运行状态；
• 在node节点执行容器健康检查。

2.3.6 kubectl

• https://kubernetes.io/zh/docs/reference/kubectl/kubectl/
• 是一个通过命令行对kubernetes集群进行管理的客户端工具。

2.3.7 etcd

• https://kubernetes.io/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/
• etcd是CoreOS公司开发目前是kubernetes默认使用的key-value数据存储系统，用于保存kubernetes的所有集群数据，etcd支持分布式集群功能，生产环境使用时需要为etcd数据提供定期备份机制。
• https://etcd.io #官网
• https://guthub.com/etcd-io/etcd #github

2.3.8 DNS

• https://kubernetes.io/zh/docs/tasks/administer-cluster/dns-custom-nameservers/
• DNS负载为整个集群提供DNS服务，从而实现服务之间的访问。
  • coredns
  • kube-dns：k8s v1.18之后不在支持。
  • sky-dns：k8s v1.9之后被kube-dns替代。

2.3.9 Dashboard

• https://kubernetes.io/zh/docs/tasks/access-application-cluster/web-ui-dashboard/
• Dashboard是基于网页的kubernetes用户界面，可以使用Dashboard获取运行在集群中的应用的概览信息，也可以创建或修改kubernetes资源(如Deployment、Job、DaemonSet等等)，也可以对Deployment实现弹性伸缩、发起滚动升级、重启Pod或者使用向导创建新的应用。