深入剖析Kubernetes--第五章：Kubernetes编排原理_Pod

kubernetes编排原理：Pod

1 为什么需要Pod

复习：

​ Namespace做隔离，Cgroups做限制，rootfs做文件系统

​ 容器的本质是进程

今日学习：

​ 在操作系统中，进程通常以进程组的方式“有原则”地组织在一起。

​ 一些容器之间需要紧密协作（超亲密关系）：互相之间发生直接的文件交换、使用localhost 或者Socket文件进行本地通信、会发生非常频繁的远程调用、需要共享某些Linux Namespace（例如一个容器需要加入另一个容器的 Network Namespace）等

​ Pod是一个逻辑概念，是一组共享了某些资源的容器。Pod里所有容器都共享一个Network Namespace，实现上则需要一个中间容器–Infra容器（永远是第一个被创建的容器），其他用户定义的其他容器则通过Join Network Namespace的方式与Infra容器关联在一起。

Pod中的容器A、B：

​ 它们可以直接使用localhost进行通信

​ 他们看到的网络设备跟Infra一样

​ 一个Pod只有一个IP地址，也就是这个Pod的Network Namespace对应的IP地址

​ 所有网络资源都是一个Pod一份，被所有Pod中容器共享

​ Pod的生命周期只跟Infra容器一致，而与容器A和容器B无关

​ ps：如果为k8s开发网络插件，应考虑如何配置Pod的Network Namespace，而不是考虑每一个用户容器如何使用你的网络配置。

共享Volume：

​ kubernetes项目只需要把所有的Volume的定义都设计在Pod层级即可，Pod里的容器只要声明挂载这个Volume，就一定可以共享这个Volume对应的宿主机目录

apiVersion: v1
kind: pod
metadata:
  name: two-containers
spec:
  restartPolicy: Never
  volumes:
  - name: share-data
    hostPath:
      path: /data
  containers:
  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: share-data
      mountPath: "/usr/share/nginx/html"
  - name: debian-container
    image: debian
    volumeMounts:
    - name: share-data
      mountPath: "/pod-data"
    command: ["/bin/sh"]
    args: ["-c","echo Hello from the debian container > /pod-data/index.hgtml"]

kubectl exec two-containers -it -c nginx-container /in/bash
cd /usr/share/nginx/html/
ls
index.hgtml

WAR包与Web服务器解决方法//貌似pull失败

apiVersion: v1
kind: Pod
metadata:
  name: javaweb-2
spec:
  initContainers:
  - image: geektime/sample:v2
    name: war
    command: ["cp","/sample.war","/app"]
    volumeMounts:
    - name: app-volume
      mountPath: /app
  containers:
  - name: tomcat
    image: geektime/tomcat:7.0
    command: ["sh","-c","/root/apache-tomcat-7.0.42-v2/bin/start.sh"]
    volumeMounts:
    - name: app-volume
      mountPath: /root/apache-tomcat-7.0.42-v2/webapps
    ports:
    - containerPort: 8080
      hostPort: 8001
  volumes:
  - name: app-volume
    emptyDir: {}

这里声明了两个容器，第一个容器使用的镜像是 geektime/sample:v2 ，这个镜像只有一个存放在根目录的 WAR 包 sample.war。另一个容器使用的镜像是 Tomcat。

WAR 包容器声明的是一个 initContainer 类型。initContainer 和 container 的区别在于，initContainer 会先于 container 且按照声明顺序运行，等 initContainer 运行完成才会运行普通的 container（有关顺序的容器：定义为Init Container）。

Pod 上挂载的 volume 是一个空目录 app-volume，即它只用于容器间共享。WAR 包容器将 app-volume 挂载到自己的 /app 目录。Tomcat 容器将 app-volume 挂载到自己的 /root/apache-tomcat-7.0.42-v2/webapps 目录下。当 WAR 包容器运行时就会将 sample.war 拷贝到对应目录上，因此 Tomcat 在运行时就能加载对应 Java 应用了。并且在之后需要更新 WAR 包时，只要打一个新的 WAR 包镜像即可。

这种通过主从容器的组织方式我们称为 Sidecar 模式。即我们可以启动一个辅助容器独立于主容器完成一些工作。

Istio 就是一个通过共享 Network Namespace 典型的 Sidecar 项目。

2.深入剖析Pod

基本结构

apiVersion: v1     #必选，版本号，例如v1
kind: Pod       　 #必选，资源类型，例如 Pod
metadata:       　 #必选，元数据
  name: string     #必选，Pod名称
  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: 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 #内存请求,容器启动的初始可用数量
    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:  #设置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-master01 ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1
FIELDS:
   apiVersion   
   kind 
   metadata