Kubernetes必备知识_gf-k8s

文章目录

• • 一、pod介绍
  • • 1.1 pod的结构
    • 1.2 Pod定义
    • 1.3 kubernetes中的命名规范
    • 1.4 Pod的资源清单
  • 二、Kubernetes架构
  • 三、网络模型
  • • 3.1 Pod网络概念模型
    • • 3.11 同一节点上的Pod网络
      • 3.12 不同节点间的Pod网络
      • 3.13 CNI简介
    • 3.2 Service网络概念模型
    • 3.3 NodePort
    • 3.4 LoadBalancer
    • 3.5 Ingress
    • 3.6 Kubectl Proxy & Port Forward
    • 3.7 总结
  • 四、kubernetes基础概念

一、pod介绍

1.1 pod的结构

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

每个Pod中都可以包含一个或者多个容器，这些容器可以分为两类：

• 主容器 pause
• 业务容器 user container1 user container2

用户程序所在的容器，数量可多可少
Pause容器，这是每个Pod都会有的一个根容器，它的作用有两个：

• 可以以它为依据，评估整个Pod的健康状态
• 可以在根容器上设置Ip地址，其它容器都此Ip（Pod IP），以实现Pod内部的网路通信

这里是Pod内部的通讯，Pod的之间的通讯采用虚拟二层网络技术来实现，我们当前环境用的是Flannel。

1.2 Pod定义

1、k8s集群中部署的最小单元
2、Pod最主要的功能管理是将一个业务或者一个调用链的所有服务（容器）
3、包含多个容器（一组容器的集合）
4、一个Pod中容器共享网络命名空间，Pod是短暂的

Pod是在`集群中运行部署应用或服务的最小单元`，他是可以支持很多容器的。Pod的设计理念是支持多个容器在一个Pod中共享网络地址和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。

比如：你运行一个操作系统发行版的软件仓库，一个nginx容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像不太可能是一个团队开发的，但是他们一块工作才能提供一个微服务，这种情况下，不同的团队各自开发构建自己的容器镜像，在部署的时候组合成一个微服务对外提供服务。这就是k8s中的Pod。
目前k8s中业务主要可以分为`长期伺服型（long-running）、批处理型（batch）、节点后台支撑型（node-daemon）和有状态应用型（stateful application）；分别对应的小机器人控制器为Deployment、Job、DaemonSet 和 StatefulSet。`

`Pod是k8s中最小部署单元，用来管理一个调用链的容器`，它之中的主容器（pause）为整个调用链的容器提供基础网络，共享存储，监控业务容器的运行状态

1.3 kubernetes中的命名规范

1、必须小写
2、必须以字母开头
3、名称当中只能够包含字母、数字和中划线(-)

1.4 Pod的资源清单

apiVersion: v1     #必选，版本号，例如v1
kind: Pod       　 #必选，资源类型，例如 Pod
metadata:       　 #必选，元数据
  name: string     #必选，Pod名称
annotations:       #选做，描述信息
  nginx: nginx
  namespace: string  #Pod所属的命名空间,默认为"default"
  labels:       　　  #自定义标签列表
    - name: string      　          
spec:  #必选，Pod中容器的详细定义
  containers:  #必选，Pod中容器列表
  - name: string   #必选，容器名称
    image: string  #必选，容器的镜像名称
    imagePullPolicy: [ Always|Never|IfNotPresent ]  #获取镜像的策略 
    command: [string]   #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]      #容器的启动命令参数列表
    workingDir: string  #容器的工作目录
    volumeMounts:       #挂载到容器内部的存储卷配置
    - name: string      #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean #是否为只读模式
    ports: #需要暴露的端口库号列表
    - name: string        #端口的名称
      containerPort: 80  #容器需要监听的端口号
      hostPort: int       #容器所在主机需要监听的端口号，默认与Container相同
      protocol: string    #端口协议，支持TCP和UDP，默认TCP
    env:   #容器运行前需设置的环境变量列表
    - name: string  #环境变量名称
      value: string #环境变量的值
    resources: #资源限制和请求的设置
      limits:  #资源限制的设置
        cpu: string     #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
        memory: string  #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
      requests: #资源请求的设置
        cpu: string    #Cpu请求，容器启动的初始可用数量
        memory: string #内存请求,容器启动的初始可用数量
    lifecycle: #生命周期钩子
		postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
		preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
    livenessProbe:  #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
      exec:       　 #对Pod容器内检查方式设置为exec方式
        command: [string]  #exec方式需要制定的命令或脚本
      httpGet:       #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
        path: string
        port: number
        host: string
        scheme: string
        HttpHeaders:
        - name: string
          value: string
      tcpSocket:     #对Pod内个容器健康检查方式设置为tcpSocket方式
         port: number
       initialDelaySeconds: 0       #容器启动完成后首次探测的时间，单位为秒
       timeoutSeconds: 0    　　    #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
       periodSeconds: 0     　　    #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
       successThreshold: 0
       failureThreshold: 0
       securityContext:
         privileged: false
  restartPolicy: [Always | Never | OnFailure]  #Pod的重启策略
  nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
  nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
  imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
  - name: string
  hostNetwork: false   #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
  volumes:   #在该pod上定义共享存储卷列表
  - name: string    #共享存储卷名称 （volumes类型有很多种）
    emptyDir: {}       #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
    hostPath: string   #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
      path: string      　　        #Pod所在宿主机的目录，将被用于同期中mount的目录
    secret:       　　　#类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
      scretname: string  
      items:     
      - key: string
        path: string
    configMap:         #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
      name: string
      items:
      - key: string
        path: string

查看每种资源的可配置项

#	在这里，可通过一个命令来查看每种资源的可配置项
#   kubectl explain 资源类型         查看某种资源可以配置的一级属性
#	kubectl explain 资源类型.属性     查看属性的子属性
[root@k8s-m-01 ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1
FIELDS:
   apiVersion   <string>
   kind <string>
   metadata     <Object>
   spec <Object>
   status       <Object>

[root@k8s-m-01 ~]# kubectl explain pod.metadata
KIND:     Pod
VERSION:  v1
RESOURCE: metadata <Object>
FIELDS:
   annotations  <map[string]string>
   clusterName  <string>
   creationTimestamp    <string>
   deletionGracePeriodSeconds   <integer>
   deletionTimestamp    <string>
   finalizers   <[]string>
   generateName <string>
   generation   <integer>
   labels       <map[string]string>
   managedFields        <[]Object>
   name <string>
   namespace    <string>
   ownerReferences      <[]Object>
   resourceVersion      <string>
   selfLink     <string>
   uid  <string>

二、Kubernetes架构

核心角色： master（管理节点）， node（计算节点），image（镜像仓库）
斜体样式

master节点：

• Master提供集群的控制
• 对集群进行决策
• 检测和影响集群事件
• Master主要由 apiserver schedule controllermanager etcd组成
• API Server 提供 REST 操作和到集群共享状态的前端，所有其他组件通过它进行交互，端口6443
• Schedule 监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行，端口10251
• controller-manager 主节点上运行控制器的组件，负责管理控制器，端口10252
• 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
• 副本控制器（Replication Controller）: 负责为系统中的每个副本控制器对象维护正确数量的 Pod
• 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
• etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库，用户无需手动干预，集群自动管理，端口2379-2380。

node节点： kubernetes的计算节点

• 维护运行pod，并提供具体应用的环境
• 计算节点设计成水平扩展，该组件在多个节点上运行
• node由kubelet，kube-proxy，和docker组成
• pod：最小部署单元，一组容器的集合，共享网络，生命周期是短暂的
• kubelet 一个在集群中每个节点上运行的代理。它保证容器都运行在 Pod 中
• kuber-proxy 是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分，维护节点上的网络规则。这些网络规则允许从集群内部或外部的网络会话与 Pod 进行网络通信
• Container Runtime 容器运行环境是负责运行容器的软件 支持多个容器运行环境: docker、 containerd、CRI-O 以及任何实现 Kubernetes CRI (容器运行环境接口)。插件（Addons）
• docker：是一个开源的应用容器引擎，基于Go语言实现，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口
• Addons插件，插件使用 Kubernetes 资源（DaemonSet、 Deployment等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间
• DNS：集群 DNS 是一个 DNS 服务器，和环境中的其他 DNS 服务器一起工作，它为 Kubernetes 服务提供 DNS 记录
• Web 界面：Dashboard 是K ubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除
• 容器资源监控 ：容器资源监控 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面
• 集群层面日志 ：机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口
• 网络插件：flannel是一个可以用于 Kubernetes 的 overlay 网络提供者，实质上是一种“覆盖网络”也就是将TCP数据包装在另一种网络里面进行路由转发和通信，目前支持UDP，VxLAN，AWS VPC和GCE路由数据转发方式。不同主机的内容实现互通互联。

三、网络模型

Kubernetes是一个强大的平台，但它的网络比较复杂，涉及很多概念，例如Pod网络，Service网络，Cluster IPs，NodePort，LoadBalancer和Ingress等等。模仿TCP/IP协议栈，把Kubernetes的网络分解为四个抽象层，从0到3，除了第0层，每一层都是构建于前一层之上，如下图所示：

第0层Node节点网络比较好理解，也就是保证K8s节点(物理或虚拟机)之间能够正常IP寻址和互通的网络，这个一般由底层(公有云或数据中心)网络基础设施支持。第0层我们假定已经存在，所以不展开。

3.1 Pod网络概念模型

Pod相当于是K8s云平台中的虚拟机，它是K8s的基本调度单位。所谓Pod网络，就是能够保证K8s集群中的所有Pods(包括同一节点上的，也包括不同节点上的Pods)，逻辑上看起来都在同一个平面网络内，能够相互做IP寻址和通信的网络，下图是Pod网络的简化概念模型：

3.11 同一节点上的Pod网络

前面提到，Pod相当于是K8s云平台中的虚拟机，实际一个Pod中可以住一个或者多个(大多数场景住一个)应用容器，这些容器共享Pod的网络栈和其它资源如Volume。那么什么是共享网络栈？同一节点上的Pod之间如何寻址和互通？我以下图样例来解释：

上图节点上展示了Pod网络所依赖的3个网络设备，eth0是节点主机上的网卡，这个是支持该节点流量出入的设备，也是支持集群节点间IP寻址和互通的设备。docker0是一个虚拟网桥，可以简单理解为一个虚拟交换机，它是支持该节点上的Pod之间进行IP寻址和互通的设备。veth0则是Pod1的虚拟网卡，是支持该Pod内容器互通和对外访问的虚拟设备。docker0网桥和veth0网卡，都是linux支持和创建的虚拟网络设备。

上图Pod1内部住了3个容器，它们都共享一个虚拟网卡veth0。内部的这些容器可以通过localhost相互访问，但是它们不能在同一端口上同时开启服务，否则会有端口冲突，这就是共享网络栈的意思。Pod1中还有一个比较特殊的叫pause的容器，这个容器运行的唯一目的是为Pod建立共享的veth0网络接口。如果你SSH到K8s集群中一个有Pod运行的节点上去，然后运行docker ps，可以看到通过pause命令运行的容器。

Pod的IP是由docker0网桥分配的，例如上图docker0网桥的IP是172.17.0.1，它给第一个Pod1分配IP为172.17.0.2。如果该节点上再启一个Pod2，那么相应的分配IP为172.17.0.3，如果再启动Pod可依次类推。因为这些Pods都连在同一个网桥上，在同一个网段内，它们可以进行IP寻址和互通，如下图所示：

从上图我们可以看到，节点内Pod网络在172.17.0.0/24这个地址空间内，而节点主机在10.100.0.0/24这个地址空间内，也就是说Pod网络和节点网络不在同一个网络内，那么不同节点间的Pod该如何IP寻址和互通呢？下一节我们来分析这个问题。

3.12 不同节点间的Pod网络

现在假设我们有两个节点主机，host1(10.100.0.2)和host2(10.100.0.3)，它们在10.100.0.0/24这个地址空间内。host1上有一个PodX(172.17.0.2)，host2上有一个PodY(172.17.1.3)，Pod网络在172.17.0.0/16这个地址空间内。注意，Pod网络的地址，是由K8s统一管理和分配的，保证集群内Pod的IP地址唯一。我们发现节点网络和Pod网络不在同一个网络地址空间内，那么host1上的PodX该如何与host2上的PodY进行互通？

实际上不同节点间的Pod网络互通，有很多技术实现方案，底层的技术细节也很复杂。为了简化描述，我把这些方案大体分为两类，一类是路由方案，另外一类是覆盖(Overlay)网络方案。

如果底层的网络是你可以控制的，比如说企业内部自建的数据中心，并且你和运维团队的关系比较好，可以采用路由方案，如下图所示：

这个方案简单理解，就是通过路由设备为K8s集群的Pod网络单独划分网段，并配置路由器支持Pod网络的转发。例如上图中，对于目标为172.17.1.0/24这个范围内的包，转发到10.100.0.3这个主机上，同样，对于目标为172.17.0.0/24这个范围内的包，转发到10.100.0.2这个主机上。当主机的eth0接口接收到来自Pod网络的包，就会向内部网桥转发，这样不同节点间的Pod就可以相互IP寻址和通信。这种方案依赖于底层的网络设备，但是不引入额外性能开销。

如果底层的网络是你无法控制的，比如说公有云网络，或者企业的运维团队不支持路由方案，可以采用覆盖(Overlay)网络方案，如下图所示：

所谓覆盖网络，就是在现有网络之上再建立一个虚拟网络，实现技术有很多，例如flannel/weavenet等等，这些方案大都采用隧道封包技术。简单理解，Pod网络的数据包，在出节点之前，会先被封装成节点网络的数据包，当数据包到达目标节点，包内的Pod网络数据包会被解封出来，再转发给节点内部的Pod网络。这种方案对底层网络没有特别依赖，但是封包解包会引入额外性能开销。

3.13 CNI简介

考虑到Pod网络实现技术众多，为了简化集成，K8s支持CNI(Container Network Interface)标准，不同的Pod网络技术可以通过CNI插件形式和K8s进行集成。节点上的Kubelet通过CNI标准接口操作Pod网路，例如添加或删除网络接口等，它不需要关心Pod网络的具体实现细节。

3.2 Service网络概念模型

我们假定在K8s集群中部署了一个Account-App应用，这个应用由4个Pod(虚拟机)组成集群一起提供服务，每一个Pod都有自己的PodIP和端口。我们再假定集群内还部署了其它应用，这些应用中有些是Account-App的消费方，也就说有Client Pod要访问Account-App的Pod集群。这个时候自然引入了两个问题：

• 服务发现(Service Discovery)： Client Pod如何发现定位Account-App集群中Pod的IP？况且Account-App集群中Pod的IP是有可能会变的(英文叫ephemeral)，这种变化包括预期的，比如Account-App重新发布，或者非预期的，例如Account-App集群中有Pod挂了，K8s对Account-App进行重新调度部署。
• 负载均衡(Load Balancing)：Client Pod如何以某种负载均衡策略去访问Account-App集群中的不同Pod实例？以实现负载分摊和HA高可用。

实际上，K8s通过在Client和Account-App的Pod集群之间引入一层Account-Serivce抽象，来解决上述问题：

• 服务发现：Account-Service提供统一的ClusterIP来解决服务发现问题，Client只需通过ClusterIP就可以访问Account-App的Pod集群，不需要关心集群中的具体Pod数量和PodIP，即使是PodIP发生变化也会被ClusterIP所屏蔽。注意，这里的ClusterIP实际是个虚拟IP，也称Virtual IP(VIP)。
• 负载均衡：Account-Service抽象层具有负载均衡的能力，支持以不同策略去访问Account-App集群中的不同Pod实例，以实现负载分摊和HA高可用。K8s中默认的负载均衡策略是RoundRobin，也可以定制其它复杂策略。

3.3 NodePort

先提前强调一下，NodePort是K8s将内部服务对外暴露的基础，后面的LoadBalancer底层有赖于NodePort。

之前我们讲了K8s网络的4层抽象，Service网络在第2层，节点网络在第0层。实际上，只有节点网络是可以直接对外暴露的，具体暴露方式要看数据中心或公有云的底层网络部署，但不管采用何种部署，节点网络对外暴露是完全没有问题的。那么现在的问题是，第2层的Service网络如何通过第0层的节点网络暴露出去？我们可以回看一下K8s服务发现的原理图，如下图所示，然后不妨思考一下，K8s集群中有哪一个角色，即掌握Service网络的所有信息，可以和Service网络以及Pod网络互通互联，同时又可以和节点网络打通？

答案是Kube-Proxy。Kube-Proxy是K8s内部服务发现的一个关键组件，事实上，它还是K8s将内部服务暴露出去的关键组件。Kube-Proxy在K8s集群中所有Worker节点上都部署有一个，它掌握Service网络的所有信息，知道怎么和Service网络以及Pod网络互通互联。如果要将Kube-Proxy和节点网络打通(从而将某个服务通过Kube-Proxy暴露出去)，只需要让Kube-Proxy在节点上暴露一个监听端口即可。这种通过Kube-Proxy在节点上暴露一个监听端口，将K8s内部服务通过Kube-Proxy暴露出去的方式，术语就叫NodePort(顾名思义，端口暴露在节点上)。下图是通过NodePort暴露服务的简化概念模型。

3.4 LoadBalancer

假设我们有一套阿里云K8s环境，要将K8s内部的一个服务通过LoadBalancer方式暴露出去，可以将服务发布(Kind: Service)的type设定为LoadBalancer。服务发布后，阿里云K8s不仅会自动创建服务的NodePort端口转发，同时会自动帮我们申请一个SLB，有独立公网IP，并且阿里云K8s会帮我们自动把SLB映射到后台K8s集群的对应NodePort上。这样，通过SLB的公网IP，我们就可以访问到K8s内部服务，阿里云SLB负载均衡器会在背后做负载均衡。

值得一提的是，如果是在本地开发测试环境里头搭建的K8s，一般不支持Load Balancer也没必要，因为通过NodePort做测试访问就够了。但是在生产环境或者公有云上的K8s，例如GCP或者阿里云K8s，基本都支持自动创建Load Balancer。

3.5 Ingress

Ingress就是一个特殊的Service，通过节点的**HostPort(80/443)**暴露出去，前置一般也有LB做负载均衡。Ingress转发到内部的其它服务，是通过集群内的Service抽象层/ClusterIP进行转发，最终转发到目标服务Pod上。Ingress的转发可以基于Path转发，也可以基于域名转发等方式，基本上你只需给它设置好转发路由表即可，功能和Nginx无本质差别。

注意，Ingress是一个7层反向代理，如果你要暴露的是4层服务，还是需要走独立LB+IP方式。

3.6 Kubectl Proxy & Port Forward

• 办法一，通过kubectl proxy命令，在本机上开启一个代理服务，通过这个代理服务，可以访问K8s集群内的任意服务。背后，这个Kubectl代理服务通过Master上的API Server间接访问K8s集群内服务，因为Master知道集群内所有服务信息。这种方式只限于7层HTTP转发。

• 办法二，通过kubectl port-forward命令，它可以在本机上开启一个转发端口，间接转发到K8s内部的某个Pod的端口上。这样我们通过本机端口就可以访问K8s集群内的某个Pod。这种方式是TCP转发，不限于HTTP。

• 办法三，通过kubectl exec命令直接连到Pod上去执行linux命令，功能类似docker exec。

3.7 总结

四、kubernetes基础概念

• cluster
  cluster是 计算、存储和网络资源的集合，kubernetes利用这些资源运行各种基于容器的应用。

• master
  master是cluster的大脑，他的主要职责是调度，即决定将应用放在那里运行。master运行linux操作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个master。

• node
  node的职责是运行容器应用。node由master管理，node负责监控并汇报容器的状态，同时根据master的要求管理容器的生命周期。node运行在linux的操作系统上，可以是物理机或者是虚拟机。

• pod
  pod是kubernetes的最小工作单元。每个pod包含一个或者多个容器。pod中的容器会作为一个整体被master调度到一个node上运行。

• kube-controller-manager
  kubernetes通常不会直接创建pod,而是通过controller来管理pod的。controller中定义了pod的部署特性，比如有几个剧本，在什么样的node上运行等。为了满足不同的业务场景，kubernetes提供了多种controller，包括deployment、replicaset、daemonset、statefulset、job等。

• deployment
  是最常用的controller（控制器）。deployment可以管理pod的多个副本，并确保pod按照期望的状态运行，滚动升级和回滚应用，扩容和缩容。

• replicaset
  实现了pod的多副本管理。使用deployment时会自动创建replicaset，也就是说deployment是通过replicaset来管理pod的多个副本的，我们通常不需要直接使用replicaset。

• daemonset
  用于每个node最多只运行一个pod副本的场景。正如其名称所示的，daemonset通常用于运行daemon

• statefuleset
  能够保证pod的每个副本在整个生命周期中名称是不变的，而其他controller不提供这个功能。当某个pod发生故障需要删除并重新启动时，pod的名称会发生变化，同时statefulset会保证副本按照固定的顺序启动、更新或者删除。、

• job
  用于运行结束就删除的应用，而其他controller中的pod通常是长期持续运行的。

• service
  deployment可以部署多个副本，每个pod 都有自己的IP，外界如何访问这些副本那？
  答案是service

  kubernetes的 service定义了外界访问一组特定pod的方式。service有自己的IP和端口，service为pod提供了负载均衡。
  kubernetes运行容器pod与访问容器这两项任务分别由controller和service执行。

• namespace
  可以将一个物理的cluster逻辑上划分成多个虚拟cluster，每个cluster就是一个namespace。不同的namespace里的资源是完全隔离的。

• kubeadm
  用来初始化集群的指令。

• kubelet
  在集群中的每个节点上用来启动 pod 和容器等

• kubectl
  用来与集群通信的命令行工具。通过 kubectl 可以部署和管理应用，查看各种资源，创建、删除和更新各种组件。

• API Server
  提供 REST 操作和到集群共享状态的前端，所有其他组件通过它进行交互。

• kube-scheduler
  主节点上的组件，该组件监视那些新创建的未指定运行节点的 Pod，并选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

• kube-proxy
  是集群中每个节点上运行的网络代理,实现 Kubernetes Service 概念的一部分。

• 知名标签（Label）、注解（Annotation）和 污点（Taint）
  Kubernetes 保留了 kubernetes.io 命名空间下的所有标签和注解。

• metadata 元数据
  metadata - 帮助唯一性标识对象的一些数据，包括一个 name 字符串、UID 和可选的 namespace等