Kubernetes(k8s)基础之二：容器编排介绍及概念

 

目录

1.k8s对象

2. 容器编排的概念

2.1、K8S是如何对容器编排？

2.2、Pod是怎么创建出来的？

2.3、Pod资源组成的应用如何提供外部访问的？

2.4、Service又是怎么关联到Pod呢？

2.5、Pod的怎么创建逻辑流程是怎样的？

2.6、YAML文件编写

2.7、用命令生成YAML

2.7.1 未部署的项目生成yaml文件

2.7.2 已经部署的项目生成yaml文件

---

1.k8s对象

Kubernetes 包含若干抽象用来表示系统状态，包括：已部署的容器化应用和负载、与它们相关的网络和磁盘资源以及有关集群正在运行的其他操作的信息。这些抽象使用 Kubernetes API 对象来表示。基本的 Kubernetes 对象包括：

• Pod(容器集)：被部署在单个节点上的，且包含一个或多个容器的容器组，Pod 是可以被创建，调度，并与 Kubernetes 管理最小部署单元，同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。容器集会将网络和存储从底层容器中抽象出来，这样，就能更加轻松地在集群中移动容器。
• Service(服务)：服务为一组 Pod 提供单一稳定的名称和地址，服务可将工作定义与容器集分离，Kubernetes 服务代理会自动将服务请求分配到正确的容器集 — 无论这个容器集会移到集群中的哪个位置，即使它已被替换，也是如此。
• Label(标签)：标签用于组织和选择基于键值对的对象组，它们被用于每一个 Kubernetes 组件。
• Volume：Volume 是pod中能够被多个容器访问的共享目录。概念、用途和目的与docker的vlume相似但不等价。
• Namespace(命名空间)：Namespace 是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的 pods, services, replication controllers 和 deployments 等都是属于某一个 namespace 的（默认是 default），而 node, persistentVolumes 等则不属于任何 namespace。

另外，Kubernetes 包含大量的被称作控制器（controllers） 的高级抽象。控制器基于基本对象构建并提供额外的功能和方便使用的特性。具体包括：

• Replication Controller(复制控制器)：复制控制器管理 Pod 的生命周期，它们保证指定数量的 Pod 在任何给定的时间都在运行，他们通过创建或删除 Pod 做到这一点。
• ReplicaSet：ReplicaSet是kubernetes中的一种副本控制器，主要作用是控制由其管理的pod，使pod副本的数量始终维持在预设的个数。
• Deployment(部署)：Deployment 是新一代用于 Pod 管理的对象，与 Replication Controller 相比，它提供了更加完善的功能，使用起来更加简单方便。
• StatefulSet：StatefulSet是Kubernetes提供的管理有状态应用的负载管理控制器API。在Pods管理的基础上，保证Pods的顺序和一致性。与Deployment一样，StatefulSet也是使用容器的Spec来创建Pod，与之不同StatefulSet创建的Pods在生命周期中会保持持久的标记（例如Pod Name）。
• DaemonSet：DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod。
• Job：Job对象通常用于运行那些仅需要执行一次的任务（例如数据库迁移，批处理脚本等等）。通过Job对象创建运行的Pod具有高可靠性，因为Job Controller会自动重启运行失败的Pod（例如Pod所在Node重启或宕机）。

2. 容器编排的概念

2.1、K8S是如何对容器编排？

在K8S集群中，容器并非最小的单位，K8S集群中最小的调度单位是Pod，容器则被封装在Pod之中。由此可知，一个容器或多个容器可以同属于在一个Pod之中。

2.2、Pod是怎么创建出来的？

Pod并不是无缘无故跑出来的，它是一个抽象的逻辑概念，那么Pod是如何创建的呢？Pod是由Pod控制器进行管理控制，其代表性的Pod控制器有Deployment、StatefulSet等。

2.3、Pod资源组成的应用如何提供外部访问的？

Pod组成的应用是通过Service这类抽象资源提供内部和外部访问的，但是service的外部访问需要端口的映射，带来的是端口映射的麻烦和操作的繁琐。为此还有一种提供外部访问的资源叫做Ingress(进口 / 准许进入 / 进入权 / 入境)。

2.4、Service又是怎么关联到Pod呢？

在上面说的Pod是由Pod控制器进行管理控制，对Pod资源对象的期望状态进行自动管理。而在Pod控制器是通过一个YAML的文件进行定义Pod资源对象的。在该文件中，还会对Pod资源对象进行打标签，用于Pod的辨识，而Servcie就是通过标签选择器，关联至同一标签类型的Pod资源对象。这样就实现了从service-->pod-->container的一个过程。

2.5、Pod的怎么创建逻辑流程是怎样的？

（1）客户端提交创建请求，可以通过API Server的Restful API，也可以使用kubectl命令行工具。支持的数据类型包括JSON和YAML。
（2）API Server处理用户请求，存储Pod数据到etcd。
（3）调度器通过API Server查看未绑定的Pod。尝试为Pod分配主机。
（4）过滤主机 (调度预选)：调度器用一组规则过滤掉不符合要求的主机。比如Pod指定了所需要的资源量，那么可用资源比Pod需要的资源量少的主机会被过滤掉。
（5）主机打分(调度优选)：对第一步筛选出的符合要求的主机进行打分，在主机打分阶段，调度器会考虑一些整体优化策略，比如把容一个Replication Controller的副本分布到不同的主机上，使用最低负载的主机等。
（6）选择主机：选择打分最高的主机，进行binding操作，结果存储到etcd中。
（7）kubelet根据调度结果执行Pod创建操作： 绑定成功后，scheduler会调用APIServer的API在etcd中创建一个boundpod对象，描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的kubelet也会定期与etcd同步boundpod信息，一旦发现应该在该工作节点上运行的boundpod对象没有更新，则调用Docker API创建并启动pod内的容器。

2.6、YAML文件编写

# yaml格式的pod定义文件完整内容：
apiVersion: v1       #必选，版本号，例如v1
kind: Pod            #必选，类型Pod
metadata:            #必选，元数据
  name: string       #必选，Pod名称
  namespace: string    #必选，Pod所属的命名空间
  labels:              #自定义标签
    - name: string     #自定义标签名字
  annotations:         #自定义注释列表
    - name: string
spec:              #必选，Pod中容器的详细定义
  containers:      #必选，Pod中容器列表
  - name: string     #必选，容器名称
    image: string    #必选，容器的镜像名称
    imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 Alawys表示下载镜像 IfnotPresent表示优先使用本地镜像，否则下载镜像，Nerver表示仅使用本地镜像
    command: [string]    #容器的启动命令列表，如不指定，使用打包时使用的启动命令
    args: [string]       #容器的启动命令参数列表
    workingDir: string   #容器的工作目录
    volumeMounts:        #挂载到容器内部的存储卷配置
    - name: string       #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
      mountPath: string    #存储卷在容器内mount的绝对路径，应少于512字符
      readOnly: boolean    #是否为只读模式
    ports:       #需要暴露的端口库号列表
    - name: string         #端口号名称
      containerPort: int   #容器需要监听的端口号
      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     #内存请求，容器启动的初始可用数量
    livenessProbe:     #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器，检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可
      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的重启策略，Always表示一旦不管以何种方式终止运行，kubelet都将重启，OnFailure表示只有Pod以非0退出码退出才重启，Nerver表示不再重启该Pod
    nodeSelector: obeject  #设置NodeSelector表示将该Pod调度到包含这个label的node上，以key：value的格式指定
    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

2.7、用命令生成YAML

2.7.1 未部署的项目生成yaml文件

kubectl create deployment nginx --image=nginx:latest -o yaml --dry-run=client > my-deployment.yaml

参数解释：

-o   yaml            指定我们的yaml文件
--dry-run=client     干跑，并不实际在k8s中执行
>                    重定向
my-deployment.yaml   yaml文件名

生成的yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  strategy: {}
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:latest
        name: nginx
        resources: {}
status: {}

2.7.2 已经部署的项目生成yaml文件

kubectl get deploy nginx -o yaml > my-deploy2.yaml

生成的yaml文件

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2021-05-18T07:53:04Z"
  generation: 1
  labels:
    app: nginx-prod
  name: nginx-prod
  namespace: default
  resourceVersion: "50579"
  uid: f67aa9b8-d1b4-4d0d-9d53-8f5ab4eab9b9
spec:
  progressDeadlineSeconds: 600
  replicas: 3
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: nginx-prod
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: nginx-prod
    spec:
      containers:
      - image: nginx:latest
        imagePullPolicy: Always
        name: nginx
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 3
  conditions:
  - lastTransitionTime: "2021-05-18T07:54:44Z"
    lastUpdateTime: "2021-05-18T07:54:44Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2021-05-18T07:53:04Z"
    lastUpdateTime: "2021-05-18T07:54:44Z"
    message: ReplicaSet "nginx-prod-665d4d645c" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 3
  replicas: 3
  updatedReplicas: 3

 使用命令生成yaml文件非常方便，你可以在此基础上做出符合实际要求的修改，生成你想要的容器，尤其是做微服务项目时，统一规划好需要部署的镜像，先创建，再用kubectl get pod命令获得镜像，最后使用kubectl run 命令运行相应的pod就可以了。