Kubernetes基础模板解读

这是一个示例.yaml文件，显示了Kubernetes部署所需的字段和对象规范：
application/deployment.yaml

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2 # tells deployment to run 2 pods matching the template 伸缩的数量
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

必填项:
在.yaml您要创建的Kubernetes对象的文件中，您需要为以下字段设置值：

• apiVersion -您正在使用哪个版本的Kubernetes API创建该对象
• kind -您要创建什么样的对象
• metadata-有助于唯一标识对象的数据，包括name字符串UID，和可选namespace
• spec -您对物体的期望状态

spec每个Kubernetes对象的对象精确格式都不同，并且包含特定于该对象的嵌套字段。该Kubernetes API参考可以帮助你找到所有你可以创建使用Kubernetes对象的规范格式。例如，spec对于格式Pod可以发现 这里和spec一个格式Deployment都可以找到 这里。

注：

• 给定种类的一个对象一次只能具有一个给定的名称。但是，如果删除对象，则可以使用相同的名称创建一个新对象。

• Kubernetes资源的名称最长可达253个字符。名称中允许的字符为：数字（0-9），小写字母（az）-，和.。

Kubernetes从三个初始名称空间开始：

• default 没有其他名称空间的对象的默认名称空间
• kube-system Kubernetes系统创建的对象的名称空间
• kube-public该名称空间是自动创建的，并且对所有用户（包括未经身份验证的用户）可读。此名称空间主要保留给集群使用，以防某些资源在整个集群中公开可见。此名称空间的公共方面仅是约定，不是要求。

Pod模板

Pod模板是Pod规范，包含在其他对象中，例如 Replication Controllers，Jobs和 DaemonSets。控制器使用Pod模板制作实际的Pod。下面的示例是Pod的简单清单，其中包含一个打印消息的容器。

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

Pod为它们的组成容器提供两种共享资源：网络和存储。
联网
每个Pod分配有一个唯一的IP地址。Pod中的每个容器都共享网络名称空间，包括IP地址和网络端口。Pod内的容器可以使用相互通信localhost。当Pod中的容器与Pod 外部的实体进行通信时，它们必须协调它们如何使用共享的网络资源（例如端口）。

存储
Pod可以指定一组共享存储。Volumes Pod中。Pod中的所有容器都可以访问共享卷，从而使这些容器可以共享数据。卷还允许Pod中的持久数据保留下来，以防其中的容器之一需要重新启动。

pod的值

值	描述
Pending	该Pod已被Kubernetes系统接受，但是尚未创建一个或多个Container映像。这包括计划之前的时间以及通过网络下载图像所花费的时间，这可能需要一段时间。
Running	Pod已绑定到节点，并且所有容器都已创建。至少一个容器仍在运行，或者正在启动或重新启动。
Succeeded	Pod中的所有容器已成功终止，并且不会重新启动。
Failed	Pod中的所有容器均已终止，并且至少一个容器因故障而终止。也就是说，容器要么以非零状态退出，要么被系统终止。
Unknown	由于某种原因，通常由于与Pod主机通信时出错而无法获得Pod的状态。

PV
除了Volume之外，kubernetes还提供了Persistent Volume的方法。Volume主要是为了存储一些有必要保存的数据,而Persistent Volume主要是为了管理集群的存储。

Persistent Volume相对独立于Pods,单独创建。比如：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi #capacity 指定 PV 的容量为 1G。
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.207.121
    path: "/nas/dg_vd"

• accessModes 指定访问模式为 ReadWriteOnce，支持的访问模式有：
  ReadWriteOnce – PV 能以 read-write 模式 mount 到单个节点。
  ReadOnlyMany – PV 能以 read-only 模式 mount 到多个节点。
  ReadWriteMany – PV 能以 read-write 模式 mount 到多个节点

• persistentVolumeReclaimPolicy 指定当 PV 的回收策略为 Recycle，支持的策略有：
  Retain – 需要管理员手工回收。
  Recycle – 清除 PV 中的数据，效果相当于执行 rm -rf /thevolume/*。
  Delete – 删除 Storage Provider 上的对应存储资源，例如 AWS EBS、GCE PD、Azure Disk、OpenStack Cinder Volume 等。

• storageClassName 指定 PV 的 class 为 nfs。相当于为 PV 设置了一个分类，PVC 可以指定 class 申请相应 class 的 PV。

• 指定 PV 在 NFS 服务器上对应的目录。

Persistent Volume对具体的存储进行配置和分配，而Pods等则可以使用Persistent Volume抽象出来的存储资源，不需要知道集群的存储细节。

Persistent Volume和Persistent Volume Claim类似Pods和Nodes的关系，创建Pods需要消耗一定的Nodes的资源。而Persistent Volume则是提供了各种存储资源，而Persistent Volume Claim提出需要的存储标准，然后从现有存储资源中匹配或者动态建立新的资源，最后将两者进行绑定。

PVC的创建

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  resources:
    requests:
      storage: 1Gi

PVC 就很简单了，只需要指定 PV 的容量，访问模式和 class。

Pods的使用
上面已经创建好了pv和pvc，pod中直接使用这个pvc即可
Pods使用的是PersistentVolumeClaim而非PersistentVolume。

apiVersion: v1
kind: Pod
metadata:
  name: testpv
  labels:
    role: web-frontend
spec:
  containers:
  - name: web
    image: nginx
    ports:
      - name: web
        containerPort: 80
    volumeMounts:
        - name: nfs
          mountPath: "/usr/share/nginx/html"
  volumes:
  - name: nfs
    persistentVolumeClaim:
      claimName: manual

与使用普通 Volume 的格式类似，在 volumes 中通过 persistentVolumeClaim 指定使用 manual申请的 Volume。
官网参考
参考nfs