K8S(Kubernetes)学习笔记

 

Kubernetes(k8s)是google提供的开源的容器集群管理系统，在Docker技术的基础上，为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能，提高了大规模容器集群管理的便捷性。

Rancher是一个开源的企业级容器管理平台

  • k8s总体架构
  • 基本概念
    • Node
    • Pod
    • service
    • Replication Controller
    • Label 
    • Volume(存储卷) 
    • Namespace（命名空间）
  • 流程

 

k8s总体架构

Kubernetes将集群机器划分为一个Master节点和一群工作节点（Node）。其中，Master节点上运行着集群管理相关的一组进程etcd、API Server、Controller Manager、Scheduler，后三个组件构成了Kubernetes的总控中心，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且全都是自动完成。

在每个Node上运行Kubelet、Proxy、Docker daemon三个组件，负责对本节点上的Pod的生命周期进行管理，以及实现服务代理的功能。

Kubernetes集群

 1.master节点

包含Etcd存储服务（可选）、Api Server进程、Controller Manager服务进程及Scheduler服务进程。

其中，Api Server进程是管理所有资源的增、删、改、查等操作的唯一入口，Controller Manager是Kubernetes所有资源对象的自动化控制中心；Kubernetes Schedule是负责资源调度（Pod调度）的进程。

master节点关联工作节点。

 2.一群工作节点，运行真正的应用程序，Node是Kubernetes集群架构中运行Pod的服务节点，用来承载pod的运行，是pod运行的宿主机。

工作node关联Master管理节点，拥有名称和IP、系统资源信息。

  • kubelet：负责本Node节点上的Pod的创建、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。
  • kube-proxy：实现Kubernetes Service的通信与负载均衡机制的重要组件
  • Docker Engine（Docker）：Docker引擎，负责本机容器的创建和管理工作

基本概念

Node

 Node是集群的工作负载节点，默认情况kubelet会向Master注册自己，一旦Node被纳入集群管理范围，kubelet会定时向Master汇报自身的情报，包括操作系统，Docker版本，机器资源情况等。

如果Node超过指定时间不上报信息，会被Master判断为“失联”，标记为Not Ready，随后Master会触发Pod转移。

Node中有一个或多个的pod，是pod运行的宿主机，pod是node中Kubernetes管理的最小运行单元。

查询pod的命令：kubectl get nodes

Pod

 Pod是Kubernetes最基本的操作单元，包含一个或多个紧密相关的容器，每个Pod中有个根容器(Pause容器)，Pause容器的状态代表整个容器组的状态，其他业务容器共享Pause的IP，即Pod IP，共享Pause挂载的Volume，这样简化了同个Pod中不同容器之间的网络问题和文件共享问题。


Kubernetes集群中，同宿主机的或不同宿主机的Pod之间要求能够TCP/IP直接通信，因此采用虚拟二层网络技术来实现，例如Flannel，Openvswitch(OVS)等，这样在同个集群中，不同的宿主机的Pod IP为不同IP段的IP，集群中的所有Pod IP都是唯一的，不同Pod之间可以直接通信。
Pod有两种类型：普通Pod和静态Pod。静态Pod即不通过K8S调度和创建，直接在某个具体的Node机器上通过具体的文件来启动。普通Pod则是由K8S创建、调度，同时数据存放在ETCD中。
Pod IP和具体的容器端口（ContainnerPort）组成一个具体的通信地址，即Endpoint。一个Pod中可以存在多个容器，可以有多个端口，Pod IP一样，即有多个Endpoint。
Pod Volume是定义在Pod之上，被各个容器挂载到自己的文件系统中，可以用分布式文件系统实现后端存储功能。
Pod中的Event事件可以用来排查问题，可以通过kubectl describe pod xxx 来查看对应的事件。
每个Pod可以对其能使用的服务器上的计算资源设置限额，一般为CPU和Memory。K8S中一般将千分之一个的CPU配置作为最小单位，用m表示，是一个绝对值，即100m对于一个Core的机器还是48个Core的机器都是一样的大小。Memory配额也是个绝对值，单位为内存字节数。
资源配额的两个参数
Requests:该资源的最小申请量，系统必须满足要求。
Limits:该资源最大允许使用量，当超过该量，K8S会kill并重启Pod。

 

service

Kubernetes中，Service是分布式集群架构的核心，一个Service对象拥有如下关键特征：

  • 拥有一个唯一指定的名字
  • 拥有一个虚拟IP（Cluster IP、Service IP、或VIP）和端口号
  • 能够体统某种远程服务能力
  • 被映射到了提供这种服务能力的一组容器应用上

一个Service可以看作一组提供相同服务的Pod的对外访问接口，Service作用于哪些Pod是通过Label Selector来定义的。RC保证Service的Pod副本实例数目保持预期水平。

Replication Controller

Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

在创建好RC后，Kubernetes会通过RC中定义的的Label筛选出对应Pod实例并实时监控其状态和数量，如果实例数量少于定义的副本数量，则会根据RC中定义的Pod模板来创建一个新的Pod，然后将新Pod调度到合适的Node上启动运行，直到Pod实例的数量达到预定目标，这个过程完全是自动化。

RC（Replication Controller）

  • 用于创建Pod的模板（template）
  • Pod期望的副本数（replicas）
  • 用于筛选目标Pod的Label Selector

RC特性说明：

Pod的缩放可以通过以下命令实现：kubectl scale rc redis-slave --replicas=3
删除RC并不会删除该RC创建的Pod，可以将副本数设置为0，即可删除对应Pod。或者通过kubectl stop /delete命令来一次性删除RC和其创建的Pod。
改变RC中Pod模板的镜像版本可以实现滚动升级（Rolling Update）。

Label 

以key/value的形式附加到各种对象上，如Pod、Service、RC、Node等，以识别这些对象，管理关联关系等。

Label和资源对象是多对多的关系，即一个Label可以被添加到多个对象上，一个对象也可以定义多个Label。

Label的作用主要用来实现精细的、多维度的资源分组管理，以便进行资源分配，调度，配置，部署等工作。
k8s通过Label Selector(标签选择器)来筛选指定Label的资源对象，类似SQL语句中的条件查询（WHERE语句）。

使用场景：

kube-controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod副本数，从而实现副本数始终保持预期数目。
kube-proxy进程通过Service的Label Selector来选择对应Pod，自动建立每个Service到对应Pod的请求转发路由表，从而实现Service的智能负载均衡机制。
kube-scheduler实现Pod定向调度：对Node定义特定的Label，并且在Pod定义文件中使用NodeSelector标签调度策略。

Volume(存储卷) 

 Volume是Pod中能够被多个容器访问的共享目录，可以让容器的数据写到宿主机上或者写文件到网络存储中

 Volume的使用方式：先在Pod上声明一个Volume，然后被一个Pod中的多个容器Mount到具体的文件目录下。

k8s的Volume与Pod生命周期相关，而与容器的生命周期无关，即容器挂掉，数据不会丢失，但是Pod挂掉，数据则会丢失。

Namespace（命名空间）

kubernetes系统通过将系统内部的对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。

Kubernetes集群在启动后，会创建一个名为“default”的Namespace，如果不特别指明Namespace，则用户创建的Pod、RC、Service都被系统创建到“default”的Namespace中。

通过使用Namespace来组织k8s的各种对象，可以实现对用户的分组，即“多租户”管理。对不同的租户还可以进行单独的资源配额设置和管理，使得整个集群的资源配置非常灵活、方便。

查询命名空间：kubectl get namespaces

查询命名空间中的POD：kubectl get pods 或者 kubectl get pods --namespace=development

流程

        通过Kubectl(k8s中的命令行工具)提交一个创建RC的请求，该请求通过API Server被写入etcd中，此时Controller Manager通过API Server的监听资源变化的接口监听到这个RC事件，分析之后，发现当前集群中还没有它所对应的Pod实例，于是根据RC里的Pod模板定义生成一个Pod对象，通过API Server写入etcd，接下来，此事件被Scheduler发现，它立即执行一个复杂的调度流程，为这个新Pod选定一个落户的Node，然后通过API Server讲这一结果写入到etcd中，随后，目标Node上运行的Kubelet进程通过API Server监测到这个“新生的”Pod，并按照它的定义，启动该Pod并任劳任怨地负责它的下半生，直到Pod的生命结束。

        随后，我们通过Kubectl提交一个新的映射到该Pod的Service的创建请求，Controller Manager会通过Label标签查询到相关联的Pod实例，然后生成Service的Endpoints信息，并通过API Server写入到etcd中，接下来，所有Node上运行的Proxy进程通过API Server查询并监听Service对象与其对应的Endpoints信息，建立一个软件方式的负载均衡器来实现Service访问到后端Pod的流量转发功能。

  • etcd 
    用于持久化存储集群中所有的资源对象，如Node、Service、Pod、RC、Namespace等；API Server提供了操作etcd的封装接口API，这些API基本上都是集群中资源对象的增删改查及监听资源变化的接口。

  • API Server 
    提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来操作资源数据，通过对相关的资源数据“全量查询”+“变化监听”，这些组件可以很“实时”地完成相关的业务功能。

  • Controller Manager 
    集群内部的管理控制中心，其主要目的是实现Kubernetes集群的故障检测和恢复的自动化工作，比如根据RC的定义完成Pod的复制或移除，以确保Pod实例数符合RC副本的定义；根据Service与Pod的管理关系，完成服务的Endpoints对象的创建和更新；其他诸如Node的发现、管理和状态监控、死亡容器所占磁盘空间及本地缓存的镜像文件的清理等工作也是由Controller Manager完成的。

  • Scheduler 
    集群中的调度器，负责Pod在集群节点中的调度分配。

  • Kubelet 
    负责本Node节点上的Pod的创建、修改、监控、删除等全生命周期管理，同时Kubelet定时“上报”本Node的状态信息到API Server里。

  • Proxy 
    实现了Service的代理与软件模式的负载均衡器。

参考文档：

https://blog.csdn.net/huwh_/article/details/77017281

 

posted @ 2019-03-12 14:34  声声慢43  阅读(714)  评论(0)  编辑  收藏  举报