一、MASTER

 Kubernetes里的Master指的是集群控制节点,在每个Kubernetes集群里都需要有一个Master来负责整个集   群的管理和控制,基本上 Kubernetes的所有控制命令都发给它,它负责具体的执行过程,我们后 面执行的所有命  令基本都是在Master上运行的。  Master通常会占据一个独立的服务器(高可用部署建议用3台服务器),主要原因 是它太重要了,是整个集群的“首脑” ,如果它宕机或者不可用,那么对集群内容器应用的管理都将失效。

在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中。 

 二、NODE

 与Master一样,  Node可以是一台物理主机,也可以是一台虚拟机。  Node是Kubernetes集群中的工作负载节 点,每个 Node都会被Master分配一些工作负载(Docker容器),当某个Node宕机时,其上的工作负载会被Master自动转移到其他节点上。

在每个Node上都运行着以下关键进程:

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

三、POD

Pod是Kubernetes最重要的基本概念,如下图所示是Pod的组成示意图,我们看到每个Pod都有一个特殊的被称为“根容器” 的Pause容器。  Pause容器对应的镜像属于Kubernetes平台的一部分,除了Pause容器,每个Pod 还包含一个或多个紧密相关的用户业务容器。 

四、LABEL

Label(标签)是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对,其中key与value由用户自己指定。Label可以被附加到各种资源对象上,例如Node 、Pod 、Service 、RC等,一个资源对象可 以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上。  Label通常在资源对象定义时确定,也可以在对象创建后动态添加或者删除。

我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度的资源分组管理功能,以便灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如,部署不同版本的应用到不同的环境中;监控和分析应 用(日志记录、监控、告警)等。一些常用的Label示例如下。

版本标签:  "release":"stable" 、"release":"canary"。
环境标签:  "environment":"dev" 、"environment":"qa" 、"environment":"production"。   架构标签:  "tier":"frontend" 、"tier":"backend" 、"tier":"middleware"。
分区标签:  "partition":"customerA" 、"partition":"customerB"。
质量管控标签:  "track":"daily" 、"track":"weekly"。

五、Deployment

Deployment相对于RC的一个最大升级是我们可以随时知道当前Pod“部署” 的进度。实际上由于一个Pod的创建、调度、绑定节点及在目标Node上启动对应的容器这一完整过程需要一定的时间,所以我们期待系统启动N个 Pod副本的目标状态,实际上是一个连续变化的“部署过程”导致的最终状态。
Deployment的典型使用场景有以下几个:

创建一个Deployment对象来生成对应的Replica Set并完成Pod副本的创建
检查Deployment的状态来看部署动作是否完成(Pod副本数量是否达到预期的值)
更新Deployment以创建新的Pod(比如镜像升级)
如果当前Deployment不稳定,则回滚到一个早先的Deployment版本
暂停Deployment以便于一次性修改多个PodTemplateSpec的配置项,之后再恢复Deployment,进行新的发布
扩展Deployment以应对高负载
查看Deployment的状态,以此作为发布是否成功的指标
清理不再需要的旧版本ReplicaSets

六、Namespace          

 Namespace  (命名空间)是Kubernetes系统中的另一个非常重要的概念,  Namespace在很多情况下用于实现多租户的资源隔离。  

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

Kubernetes集群在启动后会创建一个名为default的Namespace,通过kubectl可以查看

 七、volume

Volume  (存储卷)是Pod中能够被多个容器访问的共享目录。Kubernetes的Volume概念、用途和目的与Docker的Volume比较类似,但两者不能等价。

首先,Kubernetes中的Volume被定义在Pod上,然后被 一个Pod 里的多个容器挂载到具体的文件目录下;其次,  Kubernetes中的 Volume与Pod的生命周期相同,但与容器的生命 周期不相关,当容器终 止或者重启时,Volume中的数据也不会丢失。最后,Kubernetes支持多种类型的Volume,例如GlusterFS 、Ceph等先进的分布式文件系统。

Volume的使用也比较简单,在大多数情况下,我们先在Pod上声明 一个Volume,然后在容器里引用该Volume并挂载(Mount)到容器里的 某个目录上。

八、Persistent Volume        

Volume是被定义在Pod上的,属于计算资源的一部分,而实际上,网络存储是相对独立于计算资 源而存在的一种实体资源。比如在使用虚拟机的情况下,我们通常会先定义一个网络存储,然后从中 划出一个“ 网盘”并挂接到虚拟机上。  

Persistent Volume( PV)和与之相 关联的Persistent Volume Claim( PVC)也起到了类似的作用。PV可以被理解成Kubernetes集群中的某个网络存储对应的一块存储,它与Volume类似,但有以下区别: 

PV只能是网络存储,不属于任何Node,但可以在每个Node上访问
PV并不是被定义在Pod上的,而是独立于Pod之外定义的

九、ConfigMap    

Kubernetes 中的 ConfigMap 是一种用于存储非敏感配置数据的 API 资源。它可以用来存储应用程序、服务或其他组件所需的配置信息,如环境变量、配置文件、命令行参数等。ConfigMap 提供了一种将配置数据与应用程序分离的机制,使得配置可以在不重新构建镜像的情况下进行修改和管理。

以下是一些关键概念和特性:

配置数据存储:ConfigMap 可以存储键值对形式的配置数据,也可以存储配置文件的内容。

与容器的挂载:ConfigMap 中的配置数据可以通过卷挂载(Volume Mount)的方式,直接注入到容器内部。这使得容器可以访问 ConfigMap 中的配置信息。

应用于 Pod:ConfigMap 可以被多个 Pod 共享,一个 Pod 可以引用一个或多ConfigMap。

与环境变量的关联:ConfigMap 中的配置数据可以被映射到 Pod 的环境变量中,这样应用程序可以直接从环境变量中读取配置。

动态更新:一旦 ConfigMap 中的配置数据发生变化,与之相关联的 Pod 可以自动感知到变化并重新加载配置,无需重启 Pod。

不适用于敏感数据:由于 ConfigMap 存储的数据不加密,因此不适用于存储敏感信息,如密码、密钥等。

使用 ConfigMap 可以有效地管理应用程序的配置,提高了部署的灵活性和可维护性。

十、Service

在 Kubernetes 中,Service 是一种抽象,用于定义一组 Pod 的访问方式。它提供了一种持久的虚拟 IP 地址,可以将请求路由到一组具有相同标签的 Pod。Service 使得应用程序可以通过稳定的方式被其他应用或用户访问,而无需关注后端 Pod 的具体细节。Service服务也是Kubernetes里的核心资源对象之一,Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个微服务。

它有以下一些关键概念和特性:

负载均衡:Service 会自动在其背后的一组 Pod 中实现负载均衡。当请求到达 Service 的虚拟 IP 地址时,它会将请求分发到相关联的 Pod 中的一个或多个。
服务发现:通过 Service,其他应用或服务可以轻松地发现和访问您的应用程序。无需知道后端 Pod 的具体 IP 地址,只需要知道 Service 的虚拟 IP 地址即可。
稳定的访问点:Service 提供了一个稳定的访问点,即使 Pod 的 IP 地址发生变化,也不会影响到外部应用程序的访问。
内部和外部服务:Service 可以被配置为 ClusterIP(仅内部可访问)、NodePort(外部和内部都可以访问)或 LoadBalancer(外部可访问,需要云提供商支持)类型,以满足不同场景下的需求。
服务标签:Service 通过标签选择器(Selector)来确定与其关联的后端 Pod。只有具有与 Service 标签选择器匹配的标签的 Pod 才会被 Service 所代理。
端口映射:Service 可以定义多个端口映射,将请求转发 到后端 Pod 的不同端口。

Logo

一起探索未来云端世界的核心,云原生技术专区带您领略创新、高效和可扩展的云计算解决方案,引领您在数字化时代的成功之路。

更多推荐