2、kubernetes 概述

kubernetes 概述

简介

Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 容器技术允许您打包应用程序并将其与整个运行时环境隔离，以便轻松地在不同阶段（开发、生产等）和不同环境（内部、公共云、私有云、混合云或多云）中移动容器化应用，同时仍保留全部功能。Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。

Kubernetes 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 Google 在 2014 年开源了 Kubernetes 项目。 Kubernetes 建立在Google 大规模运行生产工作负载十几年经验的基础上， 结合了社区中最优秀的想法和实践。

官方网站：https://kubernetes.io/

Github: https://github.com/kubernetes/kubernetes

Kubernetes 组件

一个 Kubernetes 集群是由一组被称作节点（node）的机器组成， 这些节点上会运行由 Kubernetes 所管理的容器化应用。 且每个集群至少有一个工作节点。

工作节点会托管所谓的 Pods，而 Pod 就是作为应用负载的组件。 控制平面管理集群中的工作节点和 Pods。 为集群提供故障转移和高可用性， 这些控制平面一般跨多主机运行，而集群也会跨多个节点运行。

Kubernetes 各个组件之间的关联:

控制平面组件（Control Plane Components）

控制平面组件会为集群做出全局决策，比如资源的调度。 以及检测和响应集群事件，例如当不满足部署的 replicas 字段时， 要启动新的 pod）。

控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个节点上启动所有控制平面组件， 并且不会在此节点上运行用户容器。

kube-apiserver

官方文档：https://kubernetes.io/zh/docs/reference/command-line-tools-reference/kube-apiserver/

APIserver是 Kubernetes 控制平面的组件， 该组件负责公开 Kubernetes API。如果需要与您的 Kubernetes 进行交互，就要通过 APIserver。APIserver是 Kubernetes 控制平面的前端，用于处理内部和外部请求。

ApiServer对外和对内都提供了一套统一的REST API，用户可以通过kubeclt命令请求ApiServer进行操作，而Kubernetes内部组件都是通过一种watch机制去监控API Server中的资源变化，然后对其做一些相应的操作。

RESTful API，是遵循 REST 架构规范的网络接口，支持与 RESTful Web 服务进行交互。是一种在网络中client和server的一种交互形式

REST，是一种软件架构风格，或者说是一种规范，其强调HTTP应当以资源为中心，并且规范了URI的风格,规范了HTTP请求动作
(GET/PUT/POST/DELETE/HEAD/OPTIONS)的使用,具有对应的语义。

REST Gihub:https://github.com/Arachni/arachni/wiki/REST-API

Kube-ApiServer作用

1、提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；

2、提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;

3、是资源配额控制的入口；

4、拥有完备的集群安全机制.

apiserver端口和ip

默认情况下，Kubernetes APIserver在 2 个端口上提供 HTTP 服务：

1. 本地端口：(不建议使用)
   • 用于测试和引导，以及主控节点上的其他组件（调度器，控制器管理器）与 API 通信
   • 没有 TLS
   • 默认为端口 8080
   • 默认 IP 为 localhost，使用 --insecure-bind-address 进行更改
   • 请求会 绕过 身份认证和鉴权模块。
2. 安全端口：
   • 默认端口 6443，可通过启动参数“--secure-port”的值来修改默认值。
   • 默认IP地址为非本地（Non-Localhost）网络端口，通过启动参数“--bind-address”设置该值；
   • 该端口用于接收客户端、dashboard等外部HTTPS请求。
   • 用于基于Tocken文件或客户端证书及HTTP Base的认证。
   • 用于基于策略的授权。

kubernetes API测试：
# curl --cacert /etc/kubernetes/ssl/ca.pem -H "Authorization: Bearer ${TOKEN}" https://172.16.0.4:6443
# curl 127.0.0.1:6443/ #返回所有的API列表
# curl 127.0.0.1:6443/apis #分组API
# curl 127.0.0.1:6443/api/v1 #带具体版本号的API
# curl 127.0.0.1:6443/version #API版本信息
# curl 127.0.0.1:6443/healthz/etcd #与etcd的心跳监测
# curl 127.0.0.1:6443/apis/autoscaling/v1 #API的详细信息
# curl 127.0.0.1:6443/metrics #指标数据

kube-scheduler

kube-scheduler组件是kubernetes默认的调度器， 负责监视新创建的、未指定运行节点（node）的 Pods。kube-scheduler是通过内置的调度算法为待调度的Pod从集群所有节点中，挑选出所有可以运行该pod的节点。然后再根据调度算法从上述node节点选择最优节点作为最终结果，并将信息写入etcd中。

node节点上的kubelet通过API Server监听到kubernetes Scheduler产生的Pod绑定信息，然后获取对应的Pod清单，下载Image，并启动容器。

kube-scheduler 调度流程

kube-scheduler 给一个 pod 做调度选择包含两个步骤：

1. Filtering（预先阶段）：根据Pod需要的CPU、内存、端口等资源情况，将满足这个pod所需资源的 Node 节点挑选出来。
2. Scoring（优选阶段）：根据当前启用的打分规则对预选出的 Node 节点进行打分，得分最高的 Node 即作为最适合的 Node ，该 Pod 就绑定（Bind）到这个 Node 。 如果存在多个得分最高的 Node，kube-scheduler 会从中随机选取一个。

调度流程：https://kubernetes.io/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/

策略：

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

• CalculateNodeLabelPriority：优先选择含有指定Label的节点。

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

kube-controller-manager

kube-controller-manager是集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理。

Controller Manager包括一些子控制器：

• 节点控制器（Node Controller）：负责在节点出现故障时进行通知和响应
• 任务控制器（Job Controller）：监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点控制器（Endpoints Controller）：填充端点（Endpoints）对象（即加入 Service 与 Pod）。它负责监听Service和对应的Pod副本的变化。
• 服务帐户和令牌控制器（Service Account & Token Controllers）：为新的命名空间创建默认帐户和 API 访问令牌

pod高可用

Controller-Manager控制器默认会每隔5秒对节点状态进行一次同步。

当node节点40秒还是无响应的话，kubernetes 判定 node 为 notready 状态。

当node节点1分钟还是无法响应的话，kubernetes 判定 node 为 unhealthy 状态。

当node节点5分钟无法响应，则kubernetes 将会开始删除失效 node 上的 pod,并在其它可用节点重建这些pod。

#节点控制器对节点状态进行同步的重复周期
--node-monitor-period duration     默认值：5s
#在将一个 Node 标记为不健康之前允许其无响应的时长上限。 
--node-monitor-grace-period duration     默认值：40s
#在节点启动期间，节点可以处于无响应状态； 但超出此标志所设置的时长仍然无响应则该节点被标记为不健康。
--node-startup-grace-period duration     默认值：1m0s
#在失效的节点上删除 Pod 时为其预留的宽限期。
--pod-eviction-timeout duration     默认值：5m0s

cloud-controller-manager

cloud-controller-manager是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。

　　cloud-controller-manager 仅运行特定于云平台的控制回路。 如果你在自己的环境中运行 Kubernetes，或者在本地计算机中运行学习环境， 所部署的环境中不需要云控制器管理器。

　　与 kube-controller-manager 类似，cloud-controller-manager 将若干逻辑上独立的 控制回路组合到同一个可执行文件中，供你以同一进程的方式运行。 你可以对其执行水平扩容(运行不止一个副本)以提升性能或者增强容错能力。

　　下面的控制器都包含对云平台驱动的依赖：

　　节点控制器(Node Controller): 用于在节点终止响应后检查云提供商以确定节点是否已被删除

　　路由控制器(Route Controller): 用于在底层云基础架构中设置路由

　　服务控制器(Service Controller): 用于创建、更新和删除云提供商负载均衡器

etcd

kubernetes官方教程:https://kubernetes.io/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/

官方文档:https://etcd.io/docs

Github:https://github.com/etcd-io/etcd

etcd 是CoreOS公司开发目前是Kubernetes默认使用的key-value数据存储系统，用于保存kubernetes的所有集群数据，etcd支持分布式集群功能，生产环境使用时需要为etcd数据提供定期备份机制。

特点:

• 简单：curl可访问的用户的API（HTTP + JSON）
• 安全：可选的SSL客户端证书认证
• 快速： 单实例每秒1000次写操作
• 可靠：使用Raft算法保证一致性

主要功能：

• 基本的key-value存储
• 监听机制
• key的过期及续约机制， 用于监控和服务发现
• 原子Compare And Swap和Compare And Delete, 用于分布式锁和leader选举

Node 组件

Node组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。

kube-proxy

kube-proxy 是Kubernetes 网络代理运行在 node 上，它反映了 node 上 Kubernetes API 中定义的服务，并可以通过一组后端进行简单的 TCP、UDP 和 SCTP 流转发或者在一组后端进行循环 TCP、UDP 和 SCTP 转发，用户必须使用 apiserver API 创建一个服务来配置代理，其实就是kube-proxy通过在主机上维护网络规则并执行连接转发来实现Kubernetes服务访问

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

Kube-Proxy 不同的版本可支持三种工作模式：

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

iptables模式请求转发图：

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(不排队调度)等。

配置使用IPVS及指定调度算法：

官方文档:https://kubernetes.io/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/#ClientConnectionConfiguration

cat /var/lib/kube-proxy/kube-proxy-config.yaml
kind: KubeProxyConfiguration
apiVersion: kubeproxy.config.k8s.io/v1alpha1
bindAddress: 172.16.0.120
clientConnection: 
  kubeconfig: "/etc/kubernetes/kube-proxy.kubeconfig"
clusterCIDR: "10.224.0.0/16"
conntrack:
  maxPerCore: 32768
  min: 131072
  tcpCloseWaitTimeout: 1h0m0s
  tcpEstablishedTimeout: 24h0m0s
healthzBindAddress: 172.16.0.120:10256
hostnameOverride: "172.16.0.120"
metricsBindAddress: 172.16.0.120:10249
mode: "ipvs"  #指定使用ipvs及调度算法
ipvs:
  scheduler: sh

kubelet

kubelet 会在集群中每个节点（node）上运行,它会监视已分配给节点的pod,保证容器（containers）都运行在 Pod 中。具体功能如下:

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

容器运行时（Container Runtime）

Container Runtime是负责运行容器的软件。

Kubernetes 支持许多容器运行软件，例如 Docker、 containerd、 CRI-O 以及 Kubernetes CRI (容器运行环境接口) 的其他任何实现。

• OCI(Open Container Initiative)：2015年Google、docker、Redhat、IBM共同成立，定义了运行标准和镜像标准。
• CRI(Container Runtime Interface)：2016 年12月Kubernetes 发布 CRI(容器运行时接口), 可以支持rkt等不同的运行时。
• CRI-O：由redhat发起并开源，用于替代docker成为kubernetes的运行时，2016年开发,2019年4月8号进入CNCF孵化。

在kubernetes1.23及默认版本使用的时dockershim。自 1.24 版起，Dockershim 已从 Kubernetes 项目中移除。

运行时流程图：

其他

kubectl

官网：https://kubernetes.io/zh/docs/reference/kubectl/kubectl/

是一个通过命令行对kubernetes集群进行管理的客户端工具。

Dashboard

官网：https://kubernetes.io/zh/docs/tasks/access-application-cluster/web-ui-dashboard/

Dashboard是基于网页的Kubernetes用户界面，可以使用Dashboard获取运行在集群中的应用的概览信息，也可以创建或者修改Kubernetes资源（如 Deployment，Job，DaemonSet 等等），也可以对Deployment实现弹性伸缩、发起滚动升级、重启 Pod 或者使用向导创建新的应用。

DNS

DNS负责为整个集群提供DNS服务，从而实现服务之间的访问。

• coredns
• kube-dns: 1.18
• sky-dns

目前使用的DNS空间主要是coredns，在以往的历史版本使用的是sky-dns（已被淘汰）

DNS组件负责为整个集群的pod提供DNS解析服务，从而实现服务之间的访问。可以为集群中的service（SVC）创建一个域名ip的对应关系。也可以为pod提供一个外部网络访问的一个DNS服务解析。