kubernetes
- 1. 什么是kubernetes
- 2. 为什么要使用kubernetes
- 3. Kubernetes能做什么
- 4. 关键进程
- 5. kubernetes专业术语
- 6. Pod与service
- 7. Kubernetes架构和组件
- 7.1 etcd组件
- 7.2 API服务器
- 7.3 调度器
- 7.4 控制器管理器
- 7.5 Kubelet
- 7.6 kube-proxy
- 7.7 DNS服务器
- 7.8 Ingress控制器
1. 什么是kubernetes
首先，他是一个全新的基于容器技术的分布式架构领先方案。Kubernetes(k8s)是Google开源的容器集群管理系统（谷歌内部:Borg）。在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。
Kubernetes是一个完备的分布式系统支撑平台，具有完备的集群管理能力，多扩多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和发现机制、內建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制以及多粒度的资源配额管理能力。同时Kubernetes提供完善的管理工具，涵盖了包括开发、部署测试、运维监控在内的各个环节。
2. 为什么要使用kubernetes
总所周知kubernetes是一个容器编排工具，可以高效、批量的去管理容器；那么有人就要问了，docker有自带的docker-compose（单机编排）和docker-Swarm（多机编排），为什么还要用k8s，Docker-Compose的运用可以充分地把单物理服务器的性能充分利用起来，并且可以快速地进行持续交付，那如何高效地进行监控各个容器的健康运行情况以及崩溃后如何迁移服务呢？也就是常见的集群管理问题，此时的docker Swarm技术解决了这个问题，但是如何更加高效、智能的管理容器集群呢？这时谷歌公司内部使用很久k8s横空出世，抢占了近80%的市场份额，成为行业领头羊，为什么k8s能击败docker Swarm呢？那是因为kubernetes的这些：
- 快速部署功能：定义对应的charts，可以方便把大型的应用部署上去。
- 智能的缩扩容机制：部署时候会自动去考虑容器应该部署在哪个服务器上，以及副本的数量可以自定义。
- 自愈功能：某个节点的服务崩溃了，可以自动迁移到另外一个服务器节点来恢复来实现高可用。
- 智能的负载均衡：利用Ingress，可以实现流量通过域名访问进来时候，进行流量的分流到不同服务器上。
- 智能的滚动升降级：升级或者降级时候，会逐个替换，当自定义数量的服务升级OK后，才会进行其他的升级以及真正销毁旧的服务。
Kubernetes优势：
- 容器编排
- 轻量级
- 开源
- 弹性伸缩
- 负载均衡
Kubernetes 特点：
- 可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
- 可扩展: 模块化, 插件化, 可挂载, 可组合
- 自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展
- 快速部署应用，快速扩展应用
- 无缝对接新的应用功能
- 节省资源，优化硬件资源的使用
kubernetes特性：
- 自动装箱：基于资源依赖及其约束能够自动完成容器的部署且不影响其可用性
- 自我修复：一旦容器崩了，可以自动启动一个新的容器代替从而实现自我修复
- 自动实现水平扩展：水平扩展（横向扩展），一个容器不够，再启动一个，可以不断的进行扩展，只要物理平台的资源足够支撑。
- 密钥和配置管理：当镜像启动为容器的时候，可以让容器自动去加载外部的配置中心的配置信息，便能完成程序的配置。
- 储存编排：把储存卷实现动态供给，当容器需要储存卷时，根据容器自身的需求创建能够满足其需要的储存卷
- 自动进行服务发现和负载均衡
- 自动发布和回滚
- 任务批处理运行
3. Kubernetes能做什么
基础的,Kubernetes可以在物理或虚拟机集群上调度和运行应用程序容器.然而,Kubernetes还允许开发人员从物理和虚拟机’脱离’,从以主机为中心的基础架构转移到以容器为中心的基础架构,这样可以提供容器固有的全部优点和益处。
Kubernetes满足了生产中运行应用程序的许多常见的需求：
- Pod提供复合应用并保留一个应用一个容器的容器模型
- 挂载外部存储
- Secret管理
- 应用健康检查
- 副本应用实例
- 横向自动扩缩容
- 服务发现
- 负载均衡
- 滚动更新
- 资源监测
- 日志采集和存储
- 支持自检和调试
- 认证和鉴权
4. 关键进程
-
Master节点上运行的负责集群管理调度的一组进程 Kubernetes API Server(kube-apiserver):是Kubernetes里所有资源的增删改查等操作的唯一入口，是集群控制的入口进程。
Kubernetes Controller Manager(kube-controller-manager):Kubernetes里所有资源对象的自动化控制中心
Kubernetes Scheduler(kube-scheduler):负责资源调度 -
Node节点上运行的负责资源创建、通信、负载均衡、Docker创建与管理的一组进程
kubelet：与Master节点密切协作实现集群管理，负责Pod对应的容器的创建、启停等任务；
kube-proxy：实现服务间的通信与负载均衡；
Docker Engine（Docker）：负责本机Docker容器的创建于管理等。
5. kubernetes专业术语
Pod和Service是Kubernetes中较为核心的两个概念。
pod是什么？
pod可以理解为容器的外壳，它为容器做了一层抽象的封装，pod里面运行容器，pod的特点是可以将多个容器加入到同一个网络名称空间中。同一个pod可以共享储存卷。
一个pod上无论是有一个容器还是有多个容器，一旦将此pod调度到某个node上运行时，这一个pod内的所有容器只能运行在同一个node上。
node是什么？
node是kubernetes集群中的工作节点，就是负责工作的。
node可以是任何形式的计算设备，能装k8s的集群代理程序，它都可以作为整个k8s集群一个成员。
标签选择器是什么？
当大量的pod运行在一个集群中时，怎么批量进行管理呢？想只控制一部分的pod时又该如何？如何挑选和检测这些pod？有人会想到通过名称来识别容器，但是pod是随时删除和创建的，名称也会随着pod的删除和创建而发生改变。这样我们就给一类的pod进行分组，就是在创建pod时为其附上app的key的一个键值对，这样我们进行批量操作时可以通过检查pod中是否存在app的key，来实现对多个pod的控制，这样就会有一个新的问题了，怎么实现对多个标签的管理呢？这里我们就可以通过标签选择器组件来实现。
标签选择器就是一种根据标签来过滤符合条件的资源对象的机制。
6. Pod与service
-
Pod是Kubernetes里最小的资源管理对象，Pod运行在Node节点上，容器运行在Pod里，Pod里包含一个根容器和一个或多个业务容器，一般来说，紧密相关联的几个业务进程会被以不同的容器镜像的形式放在同一个Pod里。
-
Node、Pod、容器间关系
Pod有两种类型，普通的Pod和静态Pod，静态Pod存放在某个具体的Node上的一个具体文件中，且只在此Node上运行；普通的Pod一旦创建，就会被放入到etcd存储中，随后会被Master节点调度到某个具体的Node上进行绑定，然后被该Node上的kubelet进程实例化为一组相关的Docker容器并启动起来。 -
Service简称(Svc)
Svc就是一个“微服务”，Svc定义了一个服务的访问入口地址，前端应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例。Service与其后端的Pod之间通过Label Selector实现“无缝对接”，Replication Controller（简称RC）的作用是通过满足要求的Pod副本数，保证Svc的服务能力和服务质量始终处于预期的标准。
这里我们思考一个问题就是后端的多个Pod副本实例保证Svc的服务能力，为前端提供服务，前端是如何访问后端的多个Pod的呢？那就的用到负载均衡了。
7. Kubernetes架构和组件
Kubernetes 组件:
Kubernetes Master控制组件，调度管理整个系统（集群），包含如下组件:
-
Kubernetes API Server
作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以RESTful API接口方式提供给外部客户和内部组件调用。维护的REST对象持久化到Etcd中存储。 -
Kubernetes Scheduler
为新建立的Pod进行节点(node)选择(即分配机器)，负责集群的资源调度。组件抽离，可以方便替换成其他调度器。 -
Kubernetes Controller
负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运行。 -
Replication Controller
管理维护Replication Controller，关联Replication Controller和Pod，保证Replication Controller定义的副本数量与实际运行Pod数量一致。 -
Node Controller
管理维护Node，定期检查Node的健康状态，标识出(失效|未失效)的Node节点。 - Namespace Controller
管理维护Namespace，定期清理无效的Namespace，包括Namesapce下的API对象，比如Pod、Service等。 -
Service Controller
管理维护Service，提供负载以及服务代理 -
EndPoints Controller
管理维护Endpoints，关联Service和Pod，创建Endpoints为Service的后端，当Pod发生变化时，实时更新Endpoints。 -
Service Account Controller
管理维护Service Account，为每个Namespace创建默认的Service Account，同时为Service Account创建Service Account Secret。 -
Persistent Volume Controller
管理维护Persistent Volume和Persistent Volume Claim，为新的Persistent Volume Claim分配Persistent Volume进行绑定，为释放的Persistent Volume执行清理回收。 -
Daemon Set Controller
管理维护Daemon Set，负责创建Daemon Pod，保证指定的Node上正常的运行Daemon Pod。 -
Deployment Controller
管理维护Deployment，关联Deployment和Replication Controller，保证运行指定数量的Pod。当Deployment更新时，控制实现Replication Controller和 Pod的更新。 -
Job Controller
管理维护Job，为Jod创建一次性任务Pod，保证完成Job指定完成的任务数目 -
Pod Autoscaler Controller
实现Pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行Pod的伸缩动作。
Kubernetes主要由以下几个核心组件组成：
| 组件名称 | 作用 |
|---|---|
| etcd | 保存整个集群的状态； |
| apiserver | 提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制； |
| controller manager | 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等； |
| scheduler | 负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上； |
| kubelet | 负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理； |
| Container runtime | 负责镜像管理以及Pod和容器的真正运行(CRI); |
| kube-proxy | 负责为Service提供cluster内部的服务发现和负载均衡； |
其他组件:
| 组件名称 | 作用 |
|---|---|
| kube-dns | 负责为整个集群提供DNS服务 |
| Ingress Controller | 为服务提供外网入口 |
| Heapster | 提供资源监控 |
| Dashboard | 提供GUI |
| Federation | 提供跨可用区的集群 |
| Fluentd-elasticsearch | 提供集群日志采集、存储与查询 |
7.1 etcd组件
创建的所有对象 - pod,ReplicationController,服务和私密凭据等,需要以持久化方式存储到某个地方,这样它们的manifest在API服务器重启和失败的时候才不会丢失.为此,Kubernetes使用了etcd
etcd是一个响应快,分布式,一致的Key-value存储.因为它是分布式的,故可以运行多个etcd实例来获取高可用性和更好的性能
唯一能直接和etcd通信的是Kubernetes的API服务器.所有其他组件通过API服务器间接地读取,写入数据到etcd.这带来一些好处,其中之一就是增强乐观锁系统,验证系统的健壮性;并且,通过把实际存储机制从其他组件抽离,未来替换起来也更容易.值得强调的是,etcd是Kubernetes存储集群状态和元数据的唯一的地方
7.2 API服务器
Kubernetes API服务器作为中心组件,其他组件或者客户端都会去调用它.以RESTful API的形式提供了可以查询,修改集群状态的CRUD(Create,Read,Update,Delete)接口.他将状态存储到etcd中
API服务器除了提供一种一致的方式将对象存储到etcd,也对这些对象做校验,这样客户端就无法存入非法的对象(直接写入存储的话是有可能的).除了检验,还会处理乐观锁,这样对于并发更新的情况,对对象做更改就不会被其他客户端覆盖
API服务器的客户端之一就是使用的命令行工具kubectl,也支持监听资源
7.3 调度器
通常不会去指定pod应该运行在哪个集群节点上,这项工作交给调度器.宏观来看,调度器的操作比较简单.就是利用API服务器的监听机制等待新创建的pod,然后给每个新的,没有节点集的pod分配节点
调度器不会命令选中的节点去运行pod.调度器做的就是通过API服务器更新pod的定义.然后API服务器再去通知Kubelet该pod已经被调度过.当目标节点上的Kubelet发现该pod被调度到本节点,他就会创建并且运行pod的容器
尽管宏观上调度的过程看起来比较简单,但实际上为pod选择最佳节点的任务并不简单.当然,最简单的调度方式是不关心节点上已经运行的pod,随机选择一个节点.另一方面,调度器可以利用高级技术,例如机器学习,来预测接下来几分钟或几小时哪种类型的pod将会被调度,然后以最大的硬件利用率,无须重新调度已运行pod的方式来调度.Kubernetes的默认调度器实现方式处于最简单和最复杂程度之间
7.4 控制器管理器
API服务器只做了存储资源到etcd和通知客户端有变更的工作.调度器则只是给pod分配节点,所以需要有活跃的组件确保系统真实状态朝API服务器定义的期望的状态收敛.这个工作由控制器管理器里的控制器来实现
单个控制器,管理器进程当前组合了多个执行不同非冲突任务的控制器.这些控制器最终会被分解到不同的进程,如果需要的话,我们能够用自定义实现替换它们每一个
7.5 Kubelet
Kubelet就是负责所有运行在工作节点上内容的组件.它第一个任务就是在API服务器中创建一个Node资源来注册该节点.然后需要持续监控API服务器是否把该节点分配给pod,然后启动pod容器.具体实现方式是告知配置好的容器进行时来从特定容器镜像运行容器,Kubelet随后持续监控运行的容器,向API服务器报告他们的状态,事件和资源消耗
Kubelet也是运行容器存活探针的组件,当探针报错时它会重启容器.最后一点,当pod从API服务器删除时,Kubelet终止容器,并通知服务器pod已经被终止了
7.6 kube-proxy
每个工作节点都会运行kube-proxy,用于确保客户端可以通过Kubernetes API连接到你定义的服务
kube-proxy确保对服务IP和端口的连接最终能到达支持服务的某个pod处.如果有多个pod支撑一个服务,那么代理会发挥对pod的负载均衡作用
7.7 DNS服务器
集群中的所有pod默认配置使用集群内部DNS服务器.这使得pod能够轻松地通过名称查询到服务,甚至是无头服务pod的IP地址
DNS服务pod通过kube-dns服务对外暴露,使得该pod能够像其他pod一样在集群中移动.服务的IP地址在集群每个容器的/etc/reslv.conf文件的nameserver中定义.kube-dns pod利用API服务器的监控机制来订阅Service和Endpoint的变动,以及DNS记录的变更,是的其客户端总是能够获取到最新的DNS信息.客观的说,在Service和Endpoint资源发生变化到DNS pod收到订阅通知时间点之间,DNS记录可能会无效
7.8 Ingress控制器
Ingress控制器运行一个反向代理服务器,根据集群中定义的Ingress,service以及Endpoint资源来配置该控制器.所以需要订阅这些资源,然后每次其中一个发生变化则更新代理服务器的配置