扮演一个应用开发者的角色，使用这个 Kubernetes 集群发布第一个容器化应用。

1. 作为一个应用开发者，你首先要做的，是制作容器的镜像。
2. 有了容器镜像之后，需要按照 Kubernetes 项目的规范和要求，将你的镜像组织为它能够"认识"的方式，然后提交上去。

什么才是 Kubernetes 项目能"认识"的方式？
就是使用 Kubernetes 的必备技能：编写配置文件，这些配置文件可以是 YAML 或者 JSON 格式的。

Kubernetes 跟 Docker 等很多项目最大的不同，就在于它不推荐你使用命令行的方式直接运行容器（虽然 Kubernetes 项目也支持这种方式，比如：kubectl run），而是希望你用 YAML 文件的方式，即：把容器的定义、参数、配置，统统记录在一个 YAML 文件中，然后用这样一句指令把它运行起来：# kubectl create -f 我的配置文件

好处：
你会有一个文件能记录下 Kubernetes 到底"run"了什么。

一、使用YAML创建Pod

YAML 文件，对应到 k8s 中，就是一个 API Object（API 对象）。当你为这个对象的各个字段填好值并提交给 k8s 之后，k8s 就会负责创建出这些对象所定义的容器或者其他类型的 API 资源。

[root@k8s-master ~]# vim pod.yaml
[root@k8s-master ~]# cat pod.yaml
---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web
    app1: abc234     #labels里面标签的值不能是纯数字
spec:
  containers:
    - name: front-end 
      image: daocloud.io/library/nginx
      ports:
        - containerPort: 80

#创建Pod
[root@k8s-master ~]# kubectl apply -f pod.yaml
注： Pod创建过程中如果出现错误，可以使用kubectl describe 进行排查。

#查看pod状态
[root@k8s-master ~]# kubectl get pods
NAME                     READY   STATUS    RESTARTS   AGE
kube100-site             1/1     Running   0          8s

[root@k8s-master ~]# kubectl get pods  -o wide
NAME                     READY   STATUS    RESTARTS   AGE     IP           NODE        NOMINATED NODE   READINESS GATES
kube100-site             1/1     Running   0          13s     10.244.2.7   k8s-node2   <none>           <none>

#查看pod输出
[root@k8s-master ~]# kubectl logs kube100-site

#查看pods定义的详细信息
[root@k8s-master ~]# kubectl get pods -o yaml

[root@k8s-master ~]# kubectl get pods -o json     #json格式

[root@k8s-master ~]# kubectl get pod kube100-site --output yaml

#kubectl get支持以Go Template方式过滤指定的信息，比如查询Pod的运行状态
[root@k8s-master ~]# kubectl get pods kube100-site --output=go-template --template={{.status.phase}}
Running

#使用 kubectl describe 支持查询Pod的状态和生命周期事件
[root@k8s-master ~]# kubectl describe pods kube100-site

#进入Pod对应的容器内部
[root@k8s-master ~]# kubectl exec -it kube100-site /bin/bash
root@kube100-site:/# ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var
root@kube100-site:/# exit 
exit

#删除pod
[root@k8s-master ~]# # kubectl delete pod kube100-site
[root@k8s-master ~]# # kubectl delete -f pod.yaml

[root@k8s-master ~]# kubectl delete pod --all   #全部删除

#修改pod信息
[root@k8s-master ~]# vim pod.yaml     #修改内容（修改名字会新建一个pod）
[root@k8s-master ~]# kubectl apply -f pod.yaml

二、yaml配置文件详解

imgae.png

除了某些强制性的命令，如：kubectl run或者expose等，会隐式创建rc或者svc，k8s还允许通过配置文件的方式来创建这些操作对象。
通常，使用配置文件的方式会比直接使用命令行更可取，因为这些文件可以进行版本控制，而且文件的变化和内容也可以进行审核，当使用及其复杂的配置来提供一个稳健、可靠和易维护的系统时，这些点就显得非常重要。
在声明定义配置文件的时候，所有的配置文件都存储在YAML或者JSON格式的文件中并且遵循k8s的资源配置方式。
kubectl可以创建、更新、删除和获得API操作对象，当前apiVersion、kind和name会组成一个API Path以供kubectl来调用。

YAML是专门用来写配置文件的语言，非常简洁和强大，使用比json更方便。它实质上是一种通用的数据串行化格式。
kubernetes中用来定义YAML文件创建Pod和创建Deployment等资源。

• 使用YAML用于K8s的定义的好处：
  1.便捷性： 不必添加大量的参数到命令行中执行命令
  2.可维护性：YAML文件可以通过源头控制，跟踪每次操作
  3.灵活性： YAML可以创建比命令行更加复杂的结构

• YAML语法规则：
  1.大小写敏感
  2.使用缩进表示层级关系
  3.缩进时不允许使用Tab键，只允许使用空格
  4.缩进的空格数不重要，只要相同层级的元素左侧对齐即可
  5." 表示注释，从这个字符一直到行尾，都会被解析器忽略
  注：在同一个yaml配置文件内可以同时定义多个资源（---新资源的开始）

在 k8s 中，只需要知道两种结构类型：
    1.Lists
    2.Maps   


#1. YAML  Maps
Map指的是字典，即一个Key:Value 的键值对信息。
例如：
---
apiVersion: v1
kind: Pod
注：--- 为可选的分隔符 ，当需要在一个文件中定义多个结构的时候需要使用。上述内容表示有两个键apiVersion和kind，分别对应的值为v1和Pod。

Maps的value既能够对应字符串也能够对应一个Maps。
例如：
---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web    
    
注：上述的YAML文件中，metadata这个KEY对应的值为一个Maps，而嵌套的labels这个KEY的值又是一个Map。实际使用中可视情况进行多层嵌套。

​   YAML处理器根据行缩进来知道内容之间的关联。上述例子中，使用两个空格作为缩进，但空格的数据量并不重要，
只是至少要求一个空格并且所有缩进保持一致的空格数 。例如，name和labels是相同缩进级别，因此YAML处理器知道他们属于同一map；
它知道app是lables的值因为app的缩进更大。
注意：在YAML文件中绝对不要使用tab键


#2. YAML   Lists
List即列表，就是数组
例如：
args:
 - beijing
 - shanghai
 - shenzhen
 - guangzhou

可以指定任何数量的项在列表中，每个项的定义以连字符（-）开头，并且与父元素之间存在缩进。

在JSON格式中，表示如下：
{
  "args": ["beijing"，"shanghai"，"shenzhen"，"guangzhou"]
}

当然Lists的子项也可以是Maps，Maps的子项也可以是List，例如：
---
apiVersion: v1
kind: Pod
metadata:
  name: kube100-site
  labels:
    app: web
spec:
  containers:
    - name: front-end
      image: nginx
      ports:
        - containerPort: 80
        
    - name: flaskapp-demo
      image: jcdemo/flaskapp
      ports: 8080
      
如上述文件所示，定义一个containers的List对象，每个子项都由name、image、ports组成，每个ports都有一个KEY为containerPort的Map组成，
转成JSON格式文件：
{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
        "name": "kube100-site",
        "labels": {
            "app": "web"
        },

  },
  "spec": {
        "containers": [{
            "name": "front-end",
            "image": "nginx",
            "ports": [{
                "containerPort": "80"
            }]
        }，{
            "name": "flaskapp-demo",
            "image": "jcdemo/flaskapp",
            "ports": [{
                "containerPort": "5000"
            }]
        }]
  }
}

k8s的pod中运行容器，一个包含简单的Hello World容器的pod可以通过YAML文件这样来定义：
---
apiVersion: v1
kind: Pod  deployment service
metadata:  
    name: hello-world
    
spec:      #当前pod内容的声明  
    restartPolicy: Never
    containers:
    - name: hello
      image: "ubuntu:14.04"    
      command: ["/bin/echo","hello","world"]

创建的pod名为metadata.name的值：hello-world，该名称必须是唯一的。
spec的内容为该pod中，各个容器的声明：
restartPolicy：Never表示启动后运行一次就终止这个pod。
containers[0].name为容器的名字。
containers[0].image为该启动该容器的镜像。
containers[0].command相当于Dockerfile中定义的Entrypoint，可以通过下面的方式来声明cmd的参数：
command: ["/bin/echo"]
args: ["hello","world"]

三、Pod API属性详解

Pod是 k8s 项目中的最小编排单位。将这个设计落实到 API 对象上，容器（Container）就成了 Pod 属性里一个普通的字段。

哪些属性属于 Pod 对象，哪些属性属于 Container？
Pod 扮演的是传统环境里"虚拟机"的角色。是为了使用户从传统环境（虚拟机环境）向 k8s（容器环境）的迁移，更加平滑。
把 Pod 看成传统环境里的"机器"、把容器看作是运行在这个"机器"里的"用户程序"，那么很多关于 Pod 对象的设计就非常容易理解了。凡是调度、网络、存储，以及安全相关的属性，基本上是 Pod 级别的。

共同特征是，它们描述的是"机器"这个整体，而不是里面运行的"程序"。
比如：
配置这个"机器"的网卡（即：Pod 的网络定义）
配置这个"机器"的磁盘（即：Pod 的存储定义）
配置这个"机器"的防火墙（即：Pod 的安全定义）
这台"机器"运行在哪个服务器之上（即：Pod 的调度）

1. pod属性

kind：
    指定了这个 API 对象的类型（Type），是一个 Pod，根据实际情况，此处资源类型可以是Deployment、Job、Ingress、Service等。

metadata：
    包含Pod的一些meta信息，比如名称、namespace、标签等信息。
                
spec：
    specification of the resource content 指定该资源的内容,包括一些container，storage，volume以及其他Kubernetes需要的参数，
    以及诸如是否在容器失败时重新启动容器的属性。可在特定Kubernetes API找到完整的Kubernetes Pod的属性。


#容器可选的设置属性：
    除了上述的基本属性外，还能够指定复杂的属性，包括容器启动运行的命令、使用的参数、工作目录以及每次实例化是否拉取新的副本。 
    还可以指定更深入的信息，例如容器的退出日志的位置。
容器可选的设置属性包括：
name、image、command、args、workingDir、ports、env、resource、volumeMounts、livenessProbe、readinessProbe、livecycle、
terminationMessagePath、imagePullPolicy、securityContext、stdin、stdinOnce、tty


#跟"机器"相关的配置
nodeSelector：
    是一个供用户将 Pod 与 Node 进行绑定的字段，用法：
    apiVersion: v1
    kind: Pod
    ...
    spec:
     nodeSelector:
       disktype: ssd
    表示这个 Pod 永远只能运行在携带了"disktype: ssd"标签（Label）的节点上；否则，它将调度失败。

NodeName：
    一旦 Pod 的这个字段被赋值，k8s就会被认为这个 Pod 已经经过了调度，调度的结果就是赋值的节点名字。
    这个字段一般由调度器负责设置，用户也可以设置它来"骗过"调度器，这个做法一般是在测试或者调试的时候才会用到。

HostAliases：
    定义 Pod 的 hosts 文件（比如 /etc/hosts）里的内容，用法：
    apiVersion: v1
    kind: Pod
    ...
    spec:
      hostAliases:
      - ip: "10.1.2.3"
        hostnames:
        - "foo.remote"
        - "bar.remote"
    ...
    这里设置了一组 IP 和 hostname 的数据。
    
    此Pod 启动后，/etc/hosts 的内容将如下所示：
    # cat /etc/hosts
    # Kubernetes-managed hosts file.
    127.0.0.1 localhost
    ...
    10.244.135.10 hostaliases-pod
    10.1.2.3 foo.remote
    10.1.2.3 bar.remote
    
    注意：在 k8s 中，如果要设置 hosts 文件里的内容，一定要通过这种方法。否则，如果直接修改了 hosts 文件，
    在 Pod 被删除重建之后，kubelet 会自动覆盖掉被修改的内容。

#凡是跟容器的 Linux Namespace 相关的属性，也一定是 Pod 级别的
    原因：Pod 的设计，就是要让它里面的容器尽可能多地共享 Linux Namespace，仅保留必要的隔离和限制能力。
    这样，Pod 模拟出的效果，就跟虚拟机里程序间的关系非常类似了。

举例，一个 Pod 定义 yaml 文件如下：
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true

1. 定义了 shareProcessNamespace=true
    表示这个 Pod 里的容器要共享 PID Namespace

2. 定义了两个容器：
    一个 nginx 容器
    一个开启了 tty 和 stdin 的 shell 容器
          在 Pod 的 YAML 文件里声明开启它们俩，等同于设置了 docker run 里的 -it（-i 即 stdin，-t 即 tty）参数。
          可以直接认为 tty 就是 Linux 给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。
          为了能够在 tty 中输入信息，需要同时开启 stdin（标准输入流）。

此 Pod 被创建后，就可以使用 shell 容器的 tty 跟这个容器进行交互了。

#凡是 Pod 中的容器要共享宿主机的 Namespace，也一定是 Pod 级别的定义
    比如：
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  hostNetwork: true
  hostIPC: true
  hostPID: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox
    stdin: true
    tty: true
定义了共享宿主机的 Network、IPC 和 PID Namespace。这样，此 Pod 里的所有容器，会直接使用宿主机的网络、直接与宿主机进行 IPC 通信、
看到宿主机里正在运行的所有进程。

2. 容器属性

Pod 里最重要的字段"Containers"：
    "Containers"和"Init Containers"这两个字段都属于 Pod 对容器的定义，内容也完全相同，只是 Init Containers 的生命周期，
    会先于所有的 Containers，并且严格按照定义的顺序执行。

k8s 对 Container 的定义，和 Docker 相比并没有什么太大区别。
    Docker中Image（镜像）、Command（启动命令）、workingDir（容器的工作目录）、Ports（容器要开发的端口），
    以及 volumeMounts（容器要挂载的 Volume）都是构成 k8s 中 Container 的主要字段。

3. 其他的容器属性

3.1 ImagePullPolicy 字段

定义镜像的拉取策略。之所以是一个 Container 级别的属性，是因为容器镜像本来就是 Container 定义中的一部分。

默认值： Always
    表示每次创建 Pod 都重新拉取一次镜像。
    当容器的镜像是类似于 nginx 或者 nginx:latest 这样的名字时，ImagePullPolicy 也会被认为 Always。

值：Never 或者 IfNotPresent
    表示 Pod 永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取。

3.2 Lifecycle 字段

定义 Container Lifecycle Hooks。作用是在容器状态发生变化时触发一系列"钩子"。

例子：这是 k8s 官方文档的一个 Pod YAML 文件
    在这个例子中，容器成功启动之后，在 /usr/share/message 里写入了一句"欢迎信息"（即 postStart 定义的操作）。而在这个容器被删除之前，
    我们则先调用了 nginx 的退出指令（即 preStop 定义的操作），从而实现了容器的"优雅退出"。

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh"，"-c"，"echo Hello from the postStart handler > /usr/share/message"]
      preStop:
        exec:
          command: ["/usr/sbin/nginx","-s","quit"]

1. 定义了一个 nginx 镜像的容器
2. 设置了一个 postStart 和 preStop 参数
    postStart:
        是在容器启动后，立刻执行一个指定的操作。
        注意：
            postStart 定义的操作，虽然是在 Docker 容器 ENTRYPOINT 执行之后，但它并不严格保证顺序。
              也就是说，在 postStart 启动时，ENTRYPOINT 有可能还没有结束。
              如果 postStart执行超时或者错误，k8s 会在该 Pod 的 Events 中报出该容器启动失败的错误信息，导致 Pod 也处于失败的状态。

    preStop:
        是容器被杀死之前（比如，收到了 SIGKILL 信号）。
        注意：
            preStop 操作的执行，是同步的。
              所以，它会阻塞当前的容器杀死流程，直到这个 Hook 定义操作完成之后，才允许容器被杀死，这跟 postStart 不一样。

4. 一个Pod 对象在 Kubernetes 中的生命周期

Pod 生命周期的变化，主要体现在 Pod API 对象的Status 部分，这是除了 Metadata 和 Spec 之外的第三个重要字段。
其中，pod.status.phase，就是 Pod 的当前状态，有如下几种可能的情况：


Pending：
    此状态表示Pod 的 YAML 文件已经提交给了 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。
    但这个 Pod 里有些容器因为某种原因而不能被顺利创建。比如，调度不成功。

Running：
    此状态表示Pod 已经调度成功，跟一个具体的节点绑定。它包含的容器都已经创建成功，并且至少有一个正在运行中。

Succeeded：
    此状态表示 Pod 里的所有容器都正常运行完毕，并且已经退出了。这种情况在运行一次性任务时最为常见。

Failed：
    此状态表示 Pod 里至少有一个容器以不正常的状态（非 0 的返回码）退出。
    这个状态的出现，意味着你得想办法 Debug 这个容器的应用，比如查看 Pod 的 Events 和日志。

Unknown：
    这是一个异常状态，表示 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver
    这很有可能是主从节点（Master 和 Kubelet）间的通信出现了问题。

Pod 对象的 Status 字段，还可以再细分出一组 Conditions：
    这些细分状态的值包括：PodScheduled、Ready、Initialized，以及 Unschedulable
    它们主要用于描述造成当前 Status 的具体原因是什么。

    比如，Pod 当前的 Status 是 Pending，对应的 Condition 是 Unschedulable，这表示它的调度出现了问题。
    比如，Ready 这个细分状态表示 Pod 不仅已经正常启动（Running 状态），而且已经可以对外提供服务了。
    这两者之间（Running 和 Ready）是有区别的，仔细思考一下。

    Pod 的这些状态信息，是判断应用运行情况的重要标准，尤其是 Pod 进入了非"Running"状态后，一定要能迅速做出反应，
    根据它所代表的异常情况开始跟踪和定位，而不是去手忙脚乱地查阅文档。

四、投射数据卷 Projected Volume