目录

1.kubernetes介绍

Kubernetes主要功能：

2.kubernetes架构图

3.kubernetes组件

3.1 Master 组件

kube-apiserver

ETCD

kube-controller-manager

cloud-controller-manager

kube-scheduler

3.2 节点（Node）组件

kubelet

kube-porxy

container runtime

3.3 核心附件

CNI网络插件

Flannel 通信原理

Flannel三种工作模式

flannel的模式选择和查看

DNS

Dashboard

Ingress Controller

---

1.kubernetes介绍

k8s（Kubernetes）作为容器编排生态圈中重要一员，是Google大规模容器管理系统borg的开源版本实现，它提供应用部署、维护、 扩展机制等功能，利用Kubernetes能方便地管理跨机器运行容器化的应用。当前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接运行在物理机上。kubernetes是一个开放的容器调度管理平台，不限定任何一种言语，支持java/C++/go/python等各类应用程序 。

kubernetes是一个完备的分布式系统支持平台，支持多层安全防护、准入机制、多租户应用支撑、透明的服务注册、服务发现、内建负载均衡、强大的故障发现和自我修复机制、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力,完善的管理工具，包括开发、测试、部署、运维监控，一站式的完备的分布式系统开发和支撑平台。

Kubernetes主要功能：

kubernetes是一种开源的容器编排工具，通过调度系统维持用户预期数量和状态的容器正常运行。kubernetes提供的功能：

• 1、数据卷 Pod中容器之间共享数据，可以使用数据卷。
• 2、应用程序健康检查 容器内服务可能进程堵塞无法处理请求，可以设置监控检查策略保证应用健壮性。
• 3、复制应用程序实例 控制器维护着Pod副本数量，保证一个Pod或一组同类的Pod数量始终可用。
• 4、弹性伸缩 根据设定的指标（CPU利用率）自动缩放Pod副本数。
• 5、服务发现 使用环境变量或DNS服务插件保证容器中程序发现Pod入口访问地址。
• 6、负载均衡 一组Pod副本分配一个私有的集群IP地址，负载均衡转发请求到后端容器。在集群内部其他Pod可通过这个ClusterIP访问应用。 如果到容器的流量很大，Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定
• 7、滚动更新 更新服务不中断，一次更新一个Pod，而不是同时删除整个服务。
• 8、自动部署和回滚 您可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态更改为所需状态。例如，您可以自动化 Kubernetes 来为您的部署创建新容器，删除现有容器并将它们的所有资源用于新容器。
• 9、自我修复 Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。
• 10、服务/存储编排 通过文件描述部署服务，使得应用程序部署变得更高效。Kubernetes 允许您自动挂载您选择的存储系统，例如本地存储、公共云提供商等
• 11、资源监控 Node节点组件集成cAdvisor资源收集工具，可通过Heapster汇总整个集群节点资源数据，然后存储到InfluxDB时序数据库，再由Grafana展示。
• 12、密钥与配置管理 Kubernetes 允许您存储和管理敏感信息，例如密码、OAuth 令牌和 ssh 密钥。您可以在不重建容器镜像的情况下部署和更新密钥和应用程序配置，也无需在堆栈配置中暴露密钥。
• 13、提供认证和授权 支持属性访问控制（ABAC）、角色访问控制（RBAC）认证授权策略

2.kubernetes架构图

Kubernetes主要由以下几个核心组件组成：

• etcd保存了整个集群的状态；
• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
• kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

除了核心组件，还有一些推荐的Add-ons：

• kube-dns负责为整个集群提供DNS服务
• Ingress Controller为服务提供外网入口
• Heapster提供资源监控
• Dashboard提供GUI
• Federation提供跨可用区的集群
• Fluentd-elasticsearch提供集群日志采集、存储与查询

3.kubernetes组件

3.1 Master 组件

Master组件提供集群的管理控制中心。

Master组件可以在集群中任何节点上运行。但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器。

kube-apiserver

 主节点上负责提供 Kubernetes API 服务的组件；它是 Kubernetes 控制面的前端。是整个集群中资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制。

apiserver提供了集群管理的restful api接口(鉴权、数据校验、集群变更等)，负责和其它模块之间进行数据交互，承担了通信枢纽功能。

通过kubectl操作集群资源时需要登陆到master节点之上，而跨主机调用apiserver时，直接通过master前端的负载均衡来实现。

ETCD

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。在二进制部署etcd集群的时候，必须要考虑到高可用方案，一般部署三个或者三个以上的奇数个节点，因为当master宕机时，是通过选举制度来选择master的。

kube-controller-manager

kube-controller-manager运行管理控制器，它们是集群中处理常规任务的后台线程。逻辑上，每个控制器是一个单独的进程，但为了降低复杂性，它们都被编译成单个二进制文件，并在单个进程中运行。

这些控制器包括：

• 节点（Node）控制器。
• 副本（Replication）控制器：负责维护系统中每个副本中的pod。
• 端点（Endpoints）控制器：填充Endpoints对象（即连接Services＆Pods）。
• Service Account和Token控制器：为新的Namespace 创建默认帐户访问API Token。

cloud-controller-manager

云控制器管理器负责与底层云提供商的平台交互。云控制器管理器是Kubernetes版本1.6中引入的，目前还是Alpha的功能。

云控制器管理器仅运行云提供商特定的（controller loops）控制器循环。可以通过将--cloud-provider flag设置为external启动kube-controller-manager ，来禁用控制器循环。

cloud-controller-manager 具体功能：

• 节点（Node）控制器
• 路由（Route）控制器
• Service控制器
• 卷（Volume）控制器

kube-scheduler

调度器组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

当前各个node节点资源会通过kubelet汇总到etcd中，当用户提交创建pod请求时，apiserver将请求交给controller manager处理，controller manager通知scheduler进行筛选合适的node。此时scheduler通过etcd中存储的node信息进行预选(predict)，将符合要求的node选出来。再根据优选(priorities)策略，选择最合适的node用于创建pod。

 

3.2 节点（Node）组件

节点组件运行在Node，提供Kubernetes运行时环境，以及维护Pod。

kubelet

一个在集群中每个节点上运行的代理，kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。kubelet 不会管理不是由 Kubernetes 创建的容器。

简单来说主要是三个功能：

• 接收pod的期望状态(副本数、镜像、网络等)，并调用容器运行环境(container runtime)来实现预期状态，目前container runtime基本都是docker ce。需要注意的是，pod网络是由kubelet管理的，而不是kube-proxy。
• 定时汇报节点的状态给 apiserver，作为scheduler调度的基础
• 对镜像和容器的清理工作，避免不必要的文件资源占用磁盘空间

kube-porxy

kube-proxy 是集群中每个节点上运行的网络代理，是实现service资源功能组件之一。kube-proxy 建立了pod网络和集群网络之间的关系，即 cluster ip 和 pod ip 中间的关系。不同node上的service流量转发规则会通过kube-proxy进行更新，其实是调用apiserver访问etcd进行规则更新。

service流量调度方式有三种方式: userspace(废弃，性能很差)、iptables(性能差，复杂)、ipvs(性能好，转发方式清晰)

container runtime

即容器运行环境，Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI (容器运行环境接口)。常用的是Docker CE。

3.3 核心附件

核心附件虽然不都是必须要存在的，但是为了更好使用和管理kubernetes集群，这些核心附件强烈建议安装！

CNI网络插件

Kubernetes设计了网络模型，但是却将具体实现方式交给了网络插件来实现，CNI网络插件实现的是pod之间跨宿主机进行通信。默认情况下安装好node节点后，无法跨node进行宿主机通信。

CNI网络插件有很多，比如：Flannel、Calico、Canal、Contiv、OpenContrail等，其中最常用的是Flannel和Calico两种。Flannel在node节点比较少，不夸网段时性能比较好，也是市场占有率最高的网络插件。

Flannel 通信原理

在已安装完毕flannel的node节点上，查看路由表会发现，其实flannel就是添加了一个路由信息，将跨宿主机访问pod的路由方式写到了系统路由表中。

Flannel三种工作模式

• UDP模式--已经废弃

UDP是Flannel项目最早支持的一种方式，是性能最差的方式，目前已被废弃。 用的最多的是VXLAN和host-gw模式的部署

• Host-Gateway 模式--性能最高：

只是在主机上添加前往其它主机的pod网段的路由表而已，这种模式在同一个网段内部效率非常高。

howt-gw模式的工作原理，就是将每个Flannel子网的下一跳，设置成了该子网对应的宿主机的IP地址，也就是说，宿主机（host）充当了这条容器通信路径的“网关”（Gateway），这正是host-gw的含义 所有的子网和主机的信息，都保存在Etcd中，flanneld只需要watch这些数据的变化 ，实时更新路由表就行了。 核心是IP包在封装成桢的时候，使用路由表的“下一跳”设置上的MAC地址，这样可以经过二层网络到达目的宿主机

• VXLan模式--性能较好：

VXLan(Virtual Extensible LAN 虚拟可扩容局域网)，是Linux本身就支持的模式，vxlan模型中的VTEP(VXLAN Tunnel End Point 虚拟隧道端点) 就是各个node上的flannel.1设备。

当使用vxlan模式工作时，会将数据包经过docker0转给flannel.1设备，该设备会查询到目标pod宿主机的flannel.1设备的mac地址，在数据包基础上加封一个vxlan头部，这里面有一个VNI标志，flannel默认为1，flannel.1将封装好的数据包交给宿主机网卡ens32处理。ens32再添加目标pod的宿主机ip和mac。

目标pod的flannel.1的mac地址和宿主机的IP地址都是由flannel进程通过etcd维护的。

flannel的模式选择和查看

在生产中，一般会将所有的node规划到同一个局域网下，200多台的高配置的node基本够用了。对于环境隔离要求很高的业务，也不会放到同一个k8s集群，因此跨网段进行node管理的场景不多。host-gw模式下性能损失很小，vxlan模式下性能损失较大，如果存在跨网段可以考虑flannel的混合模式，或者采用其它的CNI网络插件。

DNS

在k8s集群中pod的IP地址会发生变化，k8s通过标签选择器筛选出一组pod，这组pod共同指关联到抽象资源service，这个service拥有固定的IP地址，即cluster ip。此时无论后端的pod如何变化，都可以请求都可以通过service到达后端的pod上。

每个service有着自己的名称和cluster IP地址，可以通过IP地址直接访问到service后端对应的pod资源，也可以使用DNS将cluster ip 和 service 名称关联，实现通过service的名称访问后端pod。kubernetes的dns插件有kube-dns和coredns两种，在kubernetes 1.11 开始使用coredns较多，在此之前使用kube-dns比较多。

使用dns解析时，如果在pod外，需要使用全域名解析如：nginx-web.default.svc.cluster.local，pod内部则可以使用短域名

Dashboard

Dashboard是管理Kubernetes集群一个WEB GUI插件，一个k8s集群管理的可视化网页,可以再浏览器中实现资源配置和查看

Ingress Controller

service是将一组pod管理起来，提供了一个cluster ip和service name的统一访问入口，屏蔽了pod的ip变化。

ingress 是一种基于七层的流量转发策略，即将符合条件的域名或者location流量转发到特定的service上，而ingress仅仅是一种规则，k8s内部并没有自带代理程序完成这种规则转发。ingress-controller 是一个代理服务器，将ingress的规则能真正实现的方式，常用的有 nginx,traefik,haproxy。但是在k8s集群中，建议使用traefik，性能比haroxy强大，更新配置不需要重载服务，是首选的ingress-controller。

参考：

Kubernets中文文档

kubernetes(k8s)组件介绍及容器编排操作 （二）