Kuberneters

2022/10/8 3:23:53

本文主要是介绍Kuberneters,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

概念

  • Kuberneters解决了负载均衡器的选型、部署实施问题、服务治理、服务监控、故障处理。

  • Kuberneters没有限定任何编程接口。都可以毫无困难地映射为 Kuberneters 的 Service, 并通过标准的 TCP 通信协议进行交互。

  • Kuberneters 具有完备的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建智能负载均衡器、强大的故障发现和自我修复能力、服务滚动升级和在线扩容能力、可扩展的资源自动调度机制,以及多粒度的资源配额管理能力

  • Kuberneters 提供了完善的管理工具,这些工具涵盖了包括开发、部署测试、运维监控在内的各个环节。因此,Kuberneters是一个全新的基于容器技术的分布式架构解决方案,并且是一个一站式的完备的分布式系统开发和支撑平台。

在 Kuberneters 中, Service (服务)是分布式集群架构的核心,一个 Service对象拥有如下关键特征。
  • 拥有一个唯一指定的名字 (比如mysql-server)。
  • 拥有一个虚拟IP (ClusterIP、ServiceIP或VIP)和端口号。
  • 能够提供某种远程服务能力。
  • 被映射到了提供这种服务能力的一组容器应用上。
Kuberneters的Pod对象

Kuberneters 设计了Pod对象,将每个服务进程包装到相应的Pod中,使其成为Pod中运行的一个容器(Container)。
Kuberneters 给每个Pod贴上一个标签(Label),给运行MySQL的Pod贴上name=mysql标签,给运行PHP的Pod贴上name=php标签,然后给相应的 Service 定义标签选择器( Label Selector),意为该Service要作用于所有包含name=mysql Label的Pod上。

Pod运行在一个我们称之为节点(Node)的环境中。每个 Pod 里运行着一个特殊的被称之为Pause的容器,其他容器则为业务容器,这些业务容器共享Pause容器的网络栈和Volume挂载卷。并不是每个 Pod 和它里面运行的容器都能“映射”到一个Service上,只有那些提供服务(无论是对内还是对外)的一组Pod才会被“映射”成一个服务。

Kuberneters的集群管理

Kuberneters将集群中的机器划分为一个Master节点和一群工作节点(Node)。其中,在Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler,这些进程实现了整个集群的资源管理、 Pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能,并且都是全自动完成的。 Node作为集群中的工作节点,运行真正的应用程序,在 Node 上 Kuberneters 管理的最小运行单元是 Pod。 Node 上运行着 Kuberneters 的 kubelet、kube-proxy 服务进程,这些服务进程负责 Pod 的创建、启动、监控、重启、销毁,以及实现软件模式的负载均衡器。

Kuberneters的服务升级和服务扩容

只需为需要扩容的 Service 关联的 Pod 创建一个 RC (Replication Controller),则该 Service 的扩容以至于后来的 Service 升级等头疼问题都迎刃而解。在一个 RC 定义文件中包括以下3个关键信息。

  • 目标Pod的定义。
  • 目标 Pod 需要运行的副本数量( Replicas )
  • 要监控的目标 Pod 的标签( Label )。

在创建好 RC(系统将自动创建好 Pod)后,Kuberneters 会通过 RC 中定义的 Label 筛选出对应的 Pod 实例并实时监控其状态和数量,如果实例数量少于定义的副本数量(Replicas)

Kuberneters的Master节点

Master节点上运行着以下一组关键进程。

  • Kubernetes API Server (kube-apiserver):提供了 HTTP Rest 接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口,也是集群控制的入口进程。

  • Kubernetes Controller Manager (kube-controller-manager):Kubernetes里所有资源对象的自动化控制中心,可以理解为资源对象的“大总管”。

  • Kubernetes Scheduler (kube-scheduler):负责资源调度(Pod调度)的进程。

  • 另外,在Master节点上还需要启动一个etcd服务,Kubernetes里的所有资源对象的数据全部是保存在etcd中的。

Kuberneters的Node节点

每个Node节点上的组件包括:

  • kubelet:负责Pod对应的容器的创建、启停等任务,同时与Master节点密切协作,实现集群管理的基本功能。
  • kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件。
  • Docker Engine(容器运行时):Docker引擎,负责本机的容器创建和管理工作。

Kuberneters的Pod对象

每个Pod都有一个特殊的被称为“根容器”的Pause容器。Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod还包含一个或多个紧密相关的用户业务容器。

设计pod原因:

  • 在一组容器作为一个单元的情况下,我们难以对“整体”简单地进行判断及有效地进行行动
  • Pod里的多个业务容器共享Pause容器的IP,共享Pause容器挂接的Volume

Kubernetes要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信,这通常采用虚拟而层网络技术来实现,例如Flannel、Open vSwitch等

Pod其实有两种类型:普通的Pod及静态Pod(Static Pod),后者比较特殊,它并不存放在Kubernetes的etcd存储里,而是存放在某个具体的Node上的一个具体文件中,并且只在此Node上启动运行。而普通的Pod一旦被创建,就会被放入到etcd中存储,随后会被Kubernetes Master调度到某个具体的Node上并进行绑定(Binding),随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并且启动起来。

每个Pod都可以对其能使用的服务器上的计算资源设置限额,当前可以设置限额的计算资源有CPU与Memory两种,其中CPU的资源单位为CPU(Core)的数量,是一个绝对值而非相对值。Memory配额也是一个绝对值,它的单位是内存字节数。

Kuberneters的Label Selector

Label Selector在Kubernetes中重要的使用场景有以下几处:

  • kube-controller进程通过资源对象RC上定义都Label Selector来筛选要监控的Pod副本的数量,从而实现Pod副本的数量始终符合预期设定。

  • kube-proxy进程通过Service的Label Selector来选择对应的Pod,自动建立起每个Service到对应Pod的请求转发路由表,从而实现Service的智能负载均衡机制。

  • 通过对某些Node定义特定的Label,并且在Pod定义文件中使用NodeSelector这种标签调度策略,kube-scheduler进程可以实现Pod“定向调度”的特性。

label可以方便Kuberneters的Label进行分组管理,提升可用性。

Label具有严格的命名规则,Label定义的是Kubernetes对象的元数据(Metadata),并且用于Label Selector(标签选择器)

Kuberneters的Annotation

Annotation(注解)则是用户任意定义的“附加”信息,便于用户自行的一些查找行为

"metadata": {
  "annotations": {
    "key1" : "value1",
    "key2" : "value2"
  }
}


Kuberneters的RC

RC的定义包括如下几个部分:

  • Pod期待的副本数(replicas)。
  • 用于筛选目标Pod的Label Selector。
  • 当Pod的副本数量小于预期数量时,用于创建新Pod的Pod模版(template)。


这篇关于Kuberneters的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!


扫一扫关注最新编程教程