kubernetes基础

一 kubernetes简介

kubernetes是一个跨多主机的容器编排平台，它使用共享网络将多个主机构建成统一的集群。其中，一个或少量几个主机运行为Master作为控制中心负载管理整个集群系统，余下所有主机运行为worker node，这些工作节点使用本地和外部资源接收请求并以pod形式运行工作负载。

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

1.2 kubernetes 架构图

二 kubernetes节点

kubernetes集群主要由Master和Node两类节点组成。

Master节点包含apiserver、controller-manager、scheduler和etcd这几个组件，其中apiserver是整个集群的网关。

Node主要由kubelet、kube-proxy和容器引擎等组件构成，kubelet是工作在kubernetes集群节点之上的代理组件。

三 kubernetes组件

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 操作提供服务，并为集群的共享状态提供前端， 所有其他组件都通过该前端进行交互并将结果状态持久存储于集群状态存储系统（etcd）中。

• 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的认证。
• 用于基于策略的授权。

3.2 kube-scheduler

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，并启动容器。

3.2.2 调度策略

• LeastRequestedPriority(默认)

• 优先从备选节点列表中选择资源消耗最小的节点(CPU+内存)。

• CalculateNodeLabelPriority

• 优先选择含有指定Lable的节点。

• BalancedResourceAllocation

• 优先从备选节点列表选择各项资源使用率最均衡的节点。

3.2.3 调度过程

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

3.3 kube-controller-manager

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副本始终处于预期的工作状态。

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。

3.3.3 pod高可用机制

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

3.4 kube-proxy

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规则来实现网络转发。
• kube-proxy是kubernetes的核心网络组件，它本质上更像是pod代理及负载均衡器，负责确保集群中node、service、pod对象之间的有效通信。

3.4.2 kube-proxy工作模式

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代理模式。

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​​

3.5 kubelet

3.5.1 kubelet简介

• ​​https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kubelet/​​
• kubelet是kubernetes中最重要的组件之一是运行于每个node之上的节点代理服务，负载接收并执行master发来的指令，以及管理当前node上pod对象的容器等任务。
• 它支持从API service 以配置清单形式接收pod资源定义，或者从指定的本地目录中加载静态pod配置清单，并通过容器运行时创建、启动和监视容器。
• kubelet会持续检测当前节点上各pod的健康状态，包括基于用户自定义的探针进行存活状态探测，并在任何pod出现问题时将其重建为新实例。它还内置了一个HTTP服务器，监听TCP协议的10248和10250端口：

• 10248端口通过/healthz响应对kubelet程序自身的健康状态进行检测；
• 10250端口用于暴露kubelet API，已验证、接收并响应API server的通信请求；

3.5.2 kubelet功能

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

3.6 kubectl

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

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

四 kubernetes附件

4.1 CoreDNS

• ​​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替代。

4.2 Dashboard

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

4.3 容器资源监控系统

监控系统是分布式应用的重要基础设施，kubernetes常用的指标监控附件有Metrics-Server、kube-state-metrics和Prometheus等。

4.4 集群日志系统

日志系统是构建可观测分布式应用的另一个关键性基础设施。用于向监控系统的历史事件补充更详细的信息，帮助管理员发现和定位问题，kubernetes常用的集中式日志系统是由ElasticSearch、Fluentd和Kibaba组合提供的整体解决方案。

4.5 Ingress Controller

Ingress资源是kubernetes将集群外部HTTP/HTTPS流量引入到集群内部专用的资源类型，它仅用于控制流量的规则和配置的集合，其自身并不能进行流量穿透，要通过Ingress控制器发挥作用；目前，此类的常用项目有nginx、Traefik、Envoy、Gloo、Kong及Haproxy等。

五 kubernetes网络

5.1 通信类型

• 同一pod内的容器通信
• 各pod彼此之间通信
• pod与service间的通信
• 集群外部的流量与service间的通信

5.2 网络类型

5.2.1 节点网络

各主机自身所属的网络，相关IP地址配置在各节点的网络接口，用于各主机之间的通信。

5.2.2 Pod网络

Pod对象所属的网络，相关地址配置在pod网络接口，用于各pod间的通信。pod网络是一种虚拟网络，需要通过传统的kubenet网络插件或新式的CNI网络插件实现，常见的实现机制有Overlay和Underlay两种。

5.2.3 Service网络

service网络是一个虚拟网络，相关地址不会配置在任何主机或pod的网络接口之上，而是通过node上的kube-proxy配置为节点的IPtables或ipvs规则，进而将发往此地址的所有流量调度至service后端的各pod对象之上；service网络在kubernetes集群创建时予以指定，而各service的地址则在用户创建service时予以动态配置。

5.3 CNI插件需要实现的功能

• 所有pod间均可不经NAT机制而直接通信；
• 所有节点均可不经NAT机制直接与所有的容器通信；
• 所有pod对象都位于同一平面网络中，而且可以使用pod自身的地址直接通信；

六 kubernetes集群服务

kubernetes集群上服务大致可分为两种：API Server和服务类应用，他们的客户端要么来自集群内的其它pod，要么来自集群外部的用户或应用程序。前一种通信通常发生在pod网络和service网络之上的东西向流量；而后一种通信，尤其是访问运行于pod中的服务类应用的南北向流量，则需要先经由集群边界进入集群内部的网络中，即由节点网络到达service网络和pod网络。kubernetes上NodePort和LoadBalancer类型的service以及Ingress都可为集群引入外部流量。

七 kubernetes优势

kubernetes优势在于它提供了一个便捷有效地平台，让用户可以在物理机和虚拟机集群上调度或运行容器。kubernetes是一个支持弹性运行的分布式系统框架，是一种支撑其它平台的平台基础设施，可以帮助用户在生产环境中依托容器实施的基础框架。kubernetes的本质在于实现操作任务自动化，包括应用扩展、故障转移和部署模式等，因而他能代替用户执行大部分繁琐的操作任务，减轻用户负担，降低出错的概率。

八 kubernetes特性

8.1 自动装箱

构建于容器之上，基于资源依赖及其它约束自动完成容器部署且不影响其可用性，并在同一节点通过调度机制混合运行关键型应用和非关键型应用的工作负载，以提升资源利用率。

8.2 自我修复

支持容器故障后自动重启、节点故障后从新调度容器到其它可用节点、健康状态检查失败后关闭容器并重新创建等自我修复机制。

8.3 水边扩展

支持通过简单命令或UI手动水平扩展，以及基于CPU等资源负载率的自动扩展机制。

8.4 服务发现和负载均衡

kubernetes通过其附加组件之一的kubeDNS为系统内置了服务发现功能，它会为每个service配置dns名称，并允许集群内的客户端直接使用此名称发出访问请求，而service通过IPtables或ipvs内置了负载均衡机制。

8.5 自动发布和回滚

kubernetes支持灰度更新应用程序或其配置信息，它会监控更新过程中应用程序的健康状态，以确保不会在同一时刻杀掉所有实例，而此过程中一旦有故障发生，它会立即自动执行回滚操作。

8.6 秘钥和配置管理

kubernetes的ConfigMap实现了配置数据与Docker镜像解耦，需要时仅对配置做出变更无须从新构建Docker镜像，这为应用开发部署提供了很大的灵活性，此外，对于应用所依赖的一些敏感数据，如用户名和密码、令牌、秘钥等信息，kubernetes专门提供了secret对象使依赖解耦，即便利了应用的快速开发和交付，又提供了一定程度上的安全保障。

8.7 存储编排

kubernetes支持pod对象按需自动挂载不同类型存储系统，这包括节点本地存储、公有云服务商的云存储，以及网络存储系统，例如NFS、Ceph、Cinder、Gluster和Flocker等。

8.8 批量处理执行

除了服务型应用，kubernetes还支持批处理作业、CI，以及容器故障后恢复。

九 容器编排要素

• Docker Registry和工作仓库：通过harbor工作仓库、Docker Registry等项目实现。
• 网络：借助Flannel、calico或WeaveNet等项目实现。
• 遥测：借助Prometheus和EFK栈等项目实现。
• 容器化工作负载：借助kubernetes内置的工作负载控制器资源，甚至由社区扩展而来的各种Operator完成应用的自动化编排，包括自愈和自动扩缩容等；而便捷的用来打包要借助Helm或Kustomize等项目完成。
• 基于容器的编排系统CI/CD：借助Jenkins、Tekton、Flagger或Kepton等项目，甚至遵循GitOps规范实现应用交付、发布和部署等。