Kubernetes集群与组件

Colony

集群

集群是⼀组节点，这些节点可以是物理服务器或者虚拟机，在他上⾯安装了Kubernetes环境。    

  • Master    负责管理集群,    master协调集群中的所有活动，例如调度应⽤程序、维护应⽤程序的所需状 态、扩展应⽤程序和滚动更新。节点是Kubernetes集群中的⼯作机器，可以是物理机或虚拟机。每 个⼯作节点都有⼀个    kubelet，它是管理节点并与Kubernetes    Master节点进⾏通信的代理。节点上还 应具有处理容器操作的容器运⾏时，例如Docker或rkt。⼀个Kubernetes⼯作集群⾄少有三个节点。 Master管理集群，⽽节点 ⽤于托管正在运⾏的应⽤程序。
  • 当您在Kubernetes上部署应⽤程序时，您可以告诉master启动应⽤程序容器。Master    调度容器在集 群的节点上运⾏。节点使⽤Master 公开的Kubernetes    API与Master 通信。⽤户也可以直接使⽤ Kubernetes的 API与集群交互。

 

Pod

Pod是⼀组紧密关联的容器集合，它们共享    PID、IPC、Network    和    UTS    namespace，是Kubernetes 调度的基本单位。Pod    的设计理念是⽀持多个容器在⼀个    Pod    中共享⽹络和⽂件系统，可以通过进程 间通信和⽂件共享这种简单⾼效的⽅式组合完成服务。    

在Kubernetes中，所有对象都使⽤manifest（yaml或json）来定义，⽐如⼀个简单的nginx服务可 以定义为    nginx.yaml，它包含⼀个镜像为nginx的容器：

apiVersion: v1 #指定api版本，此值必须在kubectl apiversion中 
kind: Pod #指定创建资源的角色/类型  
metadata: #资源的元数据/属性  
  name: web04-pod #资源的名字，在同一个namespace中必须唯一  
  labels: #设定资源的标签，详情请见http://blog.csdn.net/liyingke112/article/details/77482384
    k8s-app: apache  
    version: v1  
    kubernetes.io/cluster-service: "true"  
  annotations:            #自定义注解列表  
    - name: String        #自定义注解名字  
spec:#specification of the resource content 指定该资源的内容  
  restartPolicy: Always #表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器  
  nodeSelector:     #节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1  
    zone: node1  
  containers:  
  - name: web04-pod #容器的名字  
    image: web:apache #容器使用的镜像地址  
    imagePullPolicy: Never #三个选择Always、Never、IfNotPresent

Label

Label    是识别Kubernetes对象的标签，以key/value的⽅式附加到对象上（key最⻓不能超过63字 节，value可以为空，也可以是不超过253字节的字符串）。Label不提供唯⼀性，并且实际上经常是 很多对象（如Pods）都使⽤相同的label 来标志具体的应⽤。Label定义好后其他对象可以使⽤Label Selector来选择⼀组相同label的对象（⽐如Service⽤label来选择⼀组Pod）。Label Selector⽀持 以下⼏种⽅式

  • 等式，如app=nginx和env!=production
  • 集合，如env    in    (production,    qa)
  • 多个label（它们之间是AND关系），如app=nginx,env=test

 

Namespace

Namespace    是对⼀组资源和对象的抽象集合，⽐如可以⽤来将系统内部的对象划分为不同的项⽬组或 ⽤户组。常⻅的pods,    services,deployments    等都是属于某⼀个    namespace    的（默认是default），⽽ Node,PersistentVolumes等则不属于任何namespace。

 

Deployment

是否⼿动创建Pod，如果想要创建同⼀个容器的多份拷⻉，需要⼀个个分别创建出来么，能否将Pods 划到逻辑组⾥？Deployment    确保任意时间都有指定数量的    Pod“副本”在运⾏。如果为某个    Pod    创建了Deployment  并 且指定3个副本，它会创建3个    Pod，并且持续监控它们。如果某个    Pod    不响应，那么    Deployment会 替换它，保持总数为3.如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Deployment会将其中⼀个终⽌保持总数 为3。如果在运⾏中将副本总数改为5，Deployment    会⽴刻启动2个新    Pod，保证总数为5。 Deployment    还⽀持回滚和滚动升级。

当创建Deployment时，需要指定两个东⻄：

  • Pod模板：⽤来创建Pod副本的模板
  • Label标签：Deployment需要监控的Pod的标签。

现在已经创建了Pod的⼀些副本，那么在这些副本上如何均衡负载呢？我们需要的是    Service。

 

Service

Service是应⽤服务的抽象，通过labels为应⽤提供负载均衡和服务发现。匹配labels的Pod  IP和端 ⼝列表组成endpoints，由kube-proxy负责将服务IP负载均衡到这些endpoints上。每个Service都会⾃动分配⼀个cluster   IP（仅在集群内部可访问的虚拟地址）和DNS名，其他容器 可以通过该地址或DNS来访问服务，⽽不需要了解后端容器的运⾏。    

 

基本概念与组件

Master

Master节点是Kubernetes集群的控制节点，负责整个集群的管理和控制。Master节点 上包含以下组件：

  • kube-apiserver：集群控制的⼊⼝，提供HTTP    REST服务
  • kube-controller-manager：Kubernetes集群中所有资源对象的⾃动化控制中⼼
  • kube-scheduler：负责Pod的调度

Node

Node节点是Kubernetes集群中的⼯作节点，Node上的⼯作负载由Master节点分配， ⼯作负载主要是运⾏容器应⽤。Node节点上包含以下组件：

  • kubelet：负责Pod 的创建、启动、监控、重启、销毁等⼯作，同时与Master节点协作，实 现集群管理的基本功能。
  • kube-proxy：实现Kubernetes Service的通信和负载均衡 运⾏容器化(Pod)应⽤。
  • Pod:    Pod是Kubernetes最基本的部署调度单元。每个Pod可以由⼀个或多个业务容器和⼀个根 容器(Pause容器)组成。⼀个Pod表示某个应⽤的⼀个实例。
  • ReplicaSet：是Pod副本的抽象，⽤于解决Pod的扩容和伸缩
  • Deployment：Deployment表示部署，在内部使⽤ReplicaSet来实现。可以通过Deployment来⽣成相应的ReplicaSet完成Pod副本的创建。
  • Service：Service是Kubernetes最重要的资源对象。Kubernetes中的Service对象可以对应微 服务架构中的微服务。Service 定义了服务的访问⼊⼝，服务的调⽤者通过这个地址访问Service 后端的Pod副本实例。Service通过Label    Selector同后端的Pod副本建⽴关系Deployment保 证后端Pod副本的数量，也就是保证服务的伸缩性。

核心组件

Kubernetes 主要由以下⼏个核⼼组件组成:

  1. etcd    保存了整个集群的状态，就是⼀个数据库；
  2. apiserver    提供了资源操作的唯⼀⼊⼝，并提供认证、授权、访问控制、API 注册和发现等机制；
  3. controller    manager    负责维护集群的状态，⽐如故障检测、⾃动扩展、滚动更新等；
  4. scheduler    负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
  5. kubelet    负责维护容器的⽣命周期，同时也负责Volume（CSI）和⽹络（CNI）的管理；
  6. Container    runtime    负责镜像管理以及Pod和容器的真正运⾏（CRI）；
  7. kube-proxy    负责为Service提供cluster内部的服务发现和负载均衡；

当然了除了上⾯的这些核⼼组件，还有⼀些推荐的插件：

  • kube-dns    负责为整个集群提供DNS服务
  • Ingress    Controller为服务提供外⽹⼊⼝
  • Heapster    提供资源监控
  • Dashboard    提供GUI

 

组件通信

Kubernetes    多组件之间的通信原理：

  • apiserver 负责etcd存储的所有操作，且只有apiserver才直接操作etcd集群
  • apiserver 对内（集群中的其他组件）和对外（⽤户）提供统⼀的REST   API，其他组件均通过apiserver进⾏通信
    • controller    manager、scheduler、kube-proxy和kubelet等均通过apiserver   watch   API监测 资源变化情况，并对资源作相应的操作
    • 所有需要更新资源状态的操作均通过apiserver的REST    API进⾏
  • apiserver也会直接调⽤kubelet    API（如    logs,    exec,    attach    等），默认不校验kubelet证书，但 可以通过 --kubelet-certificate-authority 开启（⽽GKE通过SSH隧道保护它们之间的通 信）

  • ⽤户通过REST    API创建⼀个Pod
  • apiserver将其写⼊etcd
  • scheduluer检测到未绑定Node的Pod，开始调度并更新Pod的Node绑定
  • kubelet检测到有新的Pod调度过来，通过container  runtime 运⾏该Pod
  • kubelet通过container runtime取到Pod状态，并更新到apiserver 中
posted @ 2021-07-23 12:10  isicman  阅读(108)  评论(0)  编辑  收藏  举报