Kubernetes是一个以容器为中心的基础架构，可以实现在物理集群或虚拟机集群上调度和运行容器，提供容器自动部署、扩展和管理的开源平台。满足了应用程序在生产环境中的一些通用需求：应用实例副本、水平自动扩展、命名与发现、负载均衡、滚动升级、资源监控等。Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化工作负载和服务，有助于声明式配置和自动化。它拥有庞大且快速发展的生态系统。

1.2 使用 kubernetes 的原因

1、快速部署功能：定义对应的charts，可以方便把大型的应用部署上去。
2、智能的缩扩容机制：部署时候会自动去考虑容器应该部署在哪个服务器上，以及副本的数量可以自定义。
3、自愈功能：某个节点的服务崩溃了，可以自动迁移到另外一个服务器节点来恢复来实现高可用。
4、智能的负载均衡：利用Ingress，可以实现流量通过域名访问进来时候，进行流量的分流到不同服务器上。
5、智能的滚动升降级：升级或者降级时候，会逐个替换，当自定义数量的服务升级OK后，才会进行其他的升级以及真正销毁旧的服务。

1.3 Kubernetes 特点

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
可扩展: 模块化, 插件化, 可挂载, 可组合
自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展
快速部署应用，快速扩展应用
无缝对接新的应用功能
节省资源，优化硬件资源的使用

1.4 kubernetes特性

1.自动装箱：基于资源依赖及其约束能够自动完成容器的部署且不影响其可用性
2.自我修复：一旦容器崩了，可以自动启动一个新的容器代替从而实现自我修复
3.自动实现水平扩展：水平扩展（横向扩展），一个容器不够，再启动一个，可以不断的进行扩展，只要物理平台的资源足够支撑。
4.密钥和配置管理：当镜像启动为容器的时候，可以让容器自动去加载外部的配置中心的配置信息，便能完成程序的配置。
5.储存编排：把储存卷实现动态供给，当容器需要储存卷时，根据容器自身的需求创建能够满足其需要的储存卷
        自动进行服务发现和负载均衡
        自动发布和回滚
        任务批处理运行

1.5 关键进程

1.Master节点上运行的负责集群管理调度的一组进程

Kubernetes API Server(kube-apiserver):是Kubernetes里所有资源的增删改查等操作的唯一入口，是集群控制的入口进程。
Kubernetes Controller Manager(kube-controller-manager):Kubernetes里所有资源对象的自动化控制中心
Kubernetes Scheduler(kube-scheduler):负责资源调度

2.Node节点上运行的负责资源创建、通信、负载均衡、Docker创建与管理的一组进程

kubelet：与Master节点密切协作实现集群管理，负责Pod对应的容器的创建、启停等任务；
kube-proxy：实现服务间的通信与负载均衡；
Docker Engine（Docker）：负责本机Docker容器的创建于管理等。

1.6 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的控制，这样就会有一个新的问题了，怎么实现对多个标签的管理呢？这里我们就可以通过标签选择器组件来实现。

标签选择器就是一种根据标签来过滤符合条件的资源对象的机制。

1.7 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的呢？那就的用到负载均衡了。

1.8 组件

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

1.9 etcd组件

创建的所有对象 - pod,ReplicationController,服务和私密凭据等,需要以持久化方式存储到某个地方,这样它们的manifest在API服务器重启和失败的时候才不会丢失.为此,Kubernetes使用了etcd

etcd是一个响应快,分布式,一致的Key-value存储.因为它是分布式的,故可以运行多个etcd实例来获取高可用性和更好的性能

唯一能直接和etcd通信的是Kubernetes的API服务器.所有其他组件通过API服务器间接地读取,写入数据到etcd.这带来一些好处,其中之一就是增强乐观锁系统,验证系统的健壮性;并且,通过把实际存储机制从其他组件抽离,未来替换起来也更容易.值得强调的是,etcd是Kubernetes存储集群状态和元数据的唯一的地方

1.10 API服务器

Kubernetes API服务器作为中心组件,其他组件或者客户端都会去调用它.以RESTful API的形式提供了可以查询,修改集群状态的CRUD(Create,Read,Update,Delete)接口.他将状态存储到etcd中

API服务器除了提供一种一致的方式将对象存储到etcd,也对这些对象做校验,这样客户端就无法存入非法的对象(直接写入存储的话是有可能的).除了检验,还会处理乐观锁,这样对于并发更新的情况,对对象做更改就不会被其他客户端覆盖

API服务器的客户端之一就是使用的命令行工具kubectl,也支持监听资源

1.11 调度器

通常不会去指定pod应该运行在哪个集群节点上,这项工作交给调度器.宏观来看,调度器的操作比较简单.就是利用API服务器的监听机制等待新创建的pod,然后给每个新的,没有节点集的pod分配节点

调度器不会命令选中的节点去运行pod.调度器做的就是通过API服务器更新pod的定义.然后API服务器再去通知Kubelet该pod已经被调度过.当目标节点上的Kubelet发现该pod被调度到本节点,他就会创建并且运行pod的容器

尽管宏观上调度的过程看起来比较简单,但实际上为pod选择最佳节点的任务并不简单.当然,最简单的调度方式是不关心节点上已经运行的pod,随机选择一个节点.另一方面,调度器可以利用高级技术,例如机器学习,来预测接下来几分钟或几小时哪种类型的pod将会被调度,然后以最大的硬件利用率,无须重新调度已运行pod的方式来调度.Kubernetes的默认调度器实现方式处于最简单和最复杂程度之间

1.12 控制器管理器

API服务器只做了存储资源到etcd和通知客户端有变更的工作.调度器则只是给pod分配节点,所以需要有活跃的组件确保系统真实状态朝API服务器定义的期望的状态收敛.这个工作由控制器管理器里的控制器来实现

单个控制器,管理器进程当前组合了多个执行不同非冲突任务的控制器.这些控制器最终会被分解到不同的进程,如果需要的话,我们能够用自定义实现替换它们每一个

1.13 Kubelet

Kubelet就是负责所有运行在工作节点上内容的组件.它第一个任务就是在API服务器中创建一个Node资源来注册该节点.然后需要持续监控API服务器是否把该节点分配给pod,然后启动pod容器.具体实现方式是告知配置好的容器进行时来从特定容器镜像运行容器,Kubelet随后持续监控运行的容器,向API服务器报告他们的状态,事件和资源消耗，负责管理pods和他们的容器，images镜像，卷组。

Kubelet也是运行容器存活探针的组件,当探针报错时它会重启容器.最后一点,当pod从API服务器删除时,Kubelet终止容器,并通知服务器pod已经被终止了

1.14 kube-proxy

每个工作节点都会运行kube-proxy,用于确保客户端可以通过Kubernetes API连接到你定义的服务

kube-proxy确保对服务IP和端口的连接最终能到达支持服务的某个pod处.如果有多个pod支撑一个服务,那么代理会发挥对pod的负载均衡作用

1.15 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记录可能会无效

1.16 Ingress控制器

Ingress控制器运行一个反向代理服务器,根据集群中定义的Ingress,service以及Endpoint资源来配置该控制器.所以需要订阅这些资源,然后每次其中一个发生变化则更新代理服务器的配置

————————————————
版权声明：本文为优快云博主「逐流·」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.youkuaiyun.com/weixin_46115601/article/details/121993360