Kubernetes学习---名词含义（1）

1、Name

Kubernetes REST API中所有对象都用Name和UID来明确的标识。
对于非唯一用户提供的属性kubernetes提供labels和annotation。

Name在一个对象中同一时间只能拥有单个Name，如果对象被删除，也可以是用相同Name创建新的对象Name用于在资源引用URL中的对象。
同一时间只能拥有一个Name，不能重复。若被删除，则可以再次使用。

UIDS是由kubernetes生成的，在kubernetes集群的整个生命周期中创建的每个对象都有不同的UID（即它们在空间和时间上时唯一的）。

2、REST API

REST API 是kubernetes系统的重要组成部分，组件之间的所有操作和通信均由API server处理的REST API 调用。

版本：

为了在兼容旧版本的同时不断升级新的API，Kubernetes支持多种API版本，每种API版本都有不同的API路径，例如/api/v1或
/apis/extensions/v1beta1。 API版本规则是通过基于API
level选择版本，而不是基于资源和域级别选择，是为了确保API能够描述一个清晰的连续的系统资源和行为的视图，能够控制访问的整个过程和控制实验性API的访问。

需要注意，API版本和软件的版本没有直接关系，不同API版本有不同程度稳定性。

3、NameSpace

kubernetes可以使用Namespaces（命名空间）创建多个虚拟集群

当团队或者项目中具有许多用户时，可以考虑使用Namespaces来区分，如果是少量用户集群，可以不考虑使用Namespaces，如需它们提供特殊性质时，可以开始使用Namespaces

用户少的时候使用Name，多的时候使用Namespaces

Namespaces为名称提供了一个范围，资源的Names在Namespaces中具有唯一性

Namespaces是一种将集群资源划分为多个用途（resource quota）的方法

相同Namespaces中的对象将具有相同的访问控制策略

Namespace是一对资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default），而node, persistentVolumes等则不属于任何namespace。

Namespace常用来隔离不同的用户，比如Kubernetes自带的服务一般运行在kube-system namespace中。

操作

kubectl可以通过–namespace或者-n选项指定namespace。如果不指定，默认为default。查看操作下,也可以通过设置–all-namespace=true来查看所有namespace下的资源。

查询

kubectl get namespace

注意：namespace包含两种状态”Active”和”Terminating”。在namespace删除过程中，namespace状态被设置成”Terminating”。

创建

1、命令行直接创建

Kubectl create namespace new-namespace

2、通过文件创建

Cat my-namespace.yaml
apiVersion：v1
kind：Namespace
metadata：
name：new-namespace
Kubectl create -f ./my-namespace.yaml

注意：命名空间名称满足正则表达式 [a-z0-9]（[-a-z0-9]*[a-z0-9]）? ,最大长度为63位

删除

Kubectl delete namespace new-namespace

注意：

1. 删除一个namespace会自动删除所有属于该namespace的资源。
2. default和kube-system命名空间不可删除。
3. PersistentVolumes是不属于任何Namespaces的，但PersistentVolumeClaim是属于某个特定的Namespaces的。
4. Events是否属于Namespaces取决于产生events的对象。

临时设置request的Namespaces

使用- -namespaces标志

$ kubectl --namespace= run nginx --image=nginx
$ kubectl --namespace= get pods

使用kubectl命令创建的Namespaces可以永久保存在context中

$ kubectl config set-context $(kubectl config current-context) --namespace=
Validate it
$ kubectl config view | grep namespace:

4、Labels 和 Selectors

标签（Labels）就是kubernetes对象上的一对键值对（key/value），标签指在用于指定对用户有意义且相关的对象的表示属性。标签可以在创建时附加到对象（Node，Pod，Service，RC，deployment等）

一个资源对象可以又任意数量的标签（labels），同一个标签（labels）也可以添加到任意的数量的资源对象上。可以随时添加和修改，每个对象都可以定义一组键值对，每个键值对给定的对象必须是唯一的。

同一个对象中key可以相同，value必须不同。

常用的labels标签：

版本标签	“release” : “stable”, “release” : “canary”
环境标签	“environment” : “dev”, “environment” : “qa”, “environment” : “production”
架构标签	“tier” : “frontend”, “tier” : “backend”, “tier” : “cache”
分区标签	“partition” : “customerA”, “partition” : “customerB”
质量管理控标签	“track” : “daily”, “track” : “weekly”

labels选择器

kubernetes中核心的组成部分

与Name和UID不同，标签不需要有唯一性。一般来说，我们期望许多对象具有相同的标签。 方便客户端/用户辨识出一组对象。

API目前支持两种选择器：equality-based（基于平等） 和 set-based（基于集合） 的。

一个为空的标签选择器（即有0个必须选择的选择器）会选择集合中的每一个对象—选择所有
一个null型标签选择器（进对于可选择的选择器字段才可能）不会返回任何对象—不选择所有

注：两个控制器的标签选择器不能在命名空间中重叠。

Equality-based requirement 基于相等的要求

基于相等的或者不相等的条件允许用标签的keys和values进行过滤。匹配的对象必须满足所有指定的标签约束，尽管他们可能也有额外的标签。有三种运算符是允许的，“=”，“==”和“!=”。前两种代表相等性（他们是同义运算符），后一种代表非相等性。

例如：
environment = production
tier != frontend

第一个选择所有key等于 environment 值为 production 的资源。后一种选择所有key为 tier 值不等于 frontend 的资源，和那些没有key为 tier 的label的资源。要过滤所有处于 production 但不是 frontend 的资源，可以使用逗号操作符， frontend：environment=production,tier!=frontend

Set-based requirement

Set-based 的标签条件允许用一组value来过滤key。支持三种操作符: in、notin 和 exists (仅针对于key符号) 。

例如：
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition

第一个例子，选择所有key等于 environment ，且value等于 production 或者 qa 的资源。

第二个例子，选择所有key等于 tier 且值是除了 frontend 和 backend 之外的资源，和那些没有标签的key是 tier
的资源。

第三个例子，选择所有有一个标签的key为partition的资源；value是什么不会被检查。

第四个例子，选择所有的没有lable的key名为 partition 的资源；value是什么不会被检查。

API

LIST和WATCH过滤

LIST和WATCH操作可以指定标签选择器来过滤使用查询参数返回的对象集。这两个要求都是允许的（在这里给出，它们会出现在URL查询字符串中）：
LIST和WATCH操作，可以使用query参数来指定label选择器来过滤返回对象的集合。两种条件都可以使用：

Set-based的要求：? labelSelector=environment%3Dproduction,tier%3Dfrontend
Equality-based的要求：? labelSelector=environment+in+%28production%2Cqa%29%2Ctier+in+%28frontend%29

两个标签选择器样式都可用于通过REST客户端列出或观看资源。例如，apiserver使用kubectl和使用基于平等的人可以写：

两种标签选择器样式，都可以通过REST客户端来list或watch资源。比如使用 kubectl 来针对 apiserver ，并且使用Equality-based的条件，可以用：

$ kubectl get pods -l environment=production,tier=frontend

或使用Set-based 要求：

$ kubectl get pods -l 'environment in (production),tier in (frontend)'

如已经提到的Set-based要求更具表现力。例如，它们可以对value执行OR运算：

$ kubectl get pods -l 'environment in (production, qa)'

或者通过exists操作符进行否定限制匹配：

$ kubectl get pods -l 'environment,environment notin (frontend)'

API对象中引用

一些Kubernetes对象，例如services和replicationcontrollers，也使用标签选择器来指定其他资源的集合，如pod。

Service和ReplicationController

一个service针对的pods的集合是用标签选择器来定义的。类似的，一个replicationcontroller管理的pods的群体也是用标签选择器来定义的。

对于这两种对象的Label选择器是用map定义在json或者yaml文件中的，并且只支持Equality-based的条件：

"selector": {
    "component" : "redis",
}

要么

selector:
    component: redis

此选择器（分别为json或yaml格式）等同于component=redis或component in (redis)。

支持set-based要求的资源

Job，Deployment，Replica Set，和Daemon Set，支持set-based要求。

selector:
  matchLabels:
    component: redis
  matchExpressions:
    - {key: tier, operator: In, values: [cache]}
    - {key: environment, operator: NotIn, values: [dev]}

matchLabels 是一个{key,value}的映射。一个单独的 {key,value} 相当于 matchExpressions 的一个元素，它的key字段是”key”,操作符是 In ，并且value数组value包含”value”。

matchExpressions是一个pod的选择器条件的list 。有效运算符包含In, NotIn, Exists,和DoesNotExist。在In和NotIn的情况下，value的组必须不能为空。所有的条件，包含 matchLabels andmatchExpressions 中的，会用AND符号连接，他们必须都被满足以完成匹配。

5、volume

参考博客：https://feisky.gitbooks.io/kubernetes/content/concepts/volume.html

docker中的volume只是磁盘中的一个目录，生命周期不受管理。

Kubernetes volume具有明确的生命周期，与Pod相同。volume的生命周期比Pod中运行的任何容器都要持久，在容器重新启动时可以保留数据；当Pod被删除不存在时，volume也将消失。

kubernetes支持许多类型的volume，Pod可以同时使用任意类型/数量的volume

内部实现中，一个volume只是一个目录，目录中可能有一些数据，pod容器可以访问这些数据。

要使用volume，pod需指定volume的类型和内容（spec.volumes字段），和映射到容器的位置（spec.containers.volumeMounts字段）。

volume类型：

emptyDir

使用emptyDir，当Pod分配到Node上时，将会创建emptyDir，并且只要Node上的Pod一直运行，Volume就会一直存。当Pod（不管任何原因）从Node上被删除时，emptyDir也同时会删除，存储的数据也将永久删除。注：删除容器不影响emptyDir。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

hostPath

hostPath允许挂载Node上的文件系统到Pod里面去。如果Pod需要使用Node上的文件，可以使用hostPath。

示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # directory location on host
      path: /data

gcePersistentDisk

gcePersistentDisk可以挂载GCE上的永久磁盘到容器，需要Kubernetes运行在GCE的VM中。与emptyDir不同，Pod删除时，gcePersistentDisk被删除，但Persistent Disk 的内容任然存在。这就意味着gcePersistentDisk能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间“切换”。

提示：使用gcePersistentDisk，必须用gcloud或使用GCE API或UI 创建PD

创建PD

使用GCE PD与pod之前，需要创建它

gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk

示例

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    # This GCE PD must already exist.
    gcePersistentDisk:
      pdName: my-data-disk
      fsType: ext4

awsElasticBlockStore

awsElasticBlockStore可以挂载AWS上的EBS盘到容器，需要Kubernetes运行在AWS的EC2上。与emptyDir Pod被删除情况不同，Volume仅被卸载，内容将被保留。这就意味着awsElasticBlockStore能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间“切换”。

提示：必须使用aws ec2 create-volumeAWS API 创建EBS Volume，然后才能使用。

创建EBS Volume

在使用EBS Volume与pod之前，需要创建它。

aws ec2 create-volume --availability-zone eu-west-1a --size 10 --volume-type gp2

AWS EBS配置示例

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-ebs
      name: test-volume
  volumes:
  - name: test-volume
    # This AWS EBS volume must already exist.
    awsElasticBlockStore:
      volumeID: 
      fsType: ext4

NFS

NFS 是Network File System的缩写，即网络文件系统。Kubernetes中通过简单地配置就可以挂载NFS到Pod中，而NFS中的数据是可以永久保存的，同时NFS支持同时写操作。Pod被删除时，Volume被卸载，内容被保留。这就意味着NFS能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间相互传递。

iSCSI

iscsi允许将现有的iscsi磁盘挂载到我们的pod中，和emptyDir不同的是，删除Pod时会被删除，但Volume只是被卸载，内容被保留，这就意味着iscsi能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间“切换”。

flocker

Flocker是一个开源的容器集群数据卷管理器。它提供各种存储后端支持的数据卷的管理和编排。

glusterfs

glusterfs，允许将Glusterfs（一个开源网络文件系统）Volume安装到pod中。不同于emptyDir，Pod被删除时，Volume只是被卸载，内容被保留。味着glusterfs能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间“切换”。

RBD

RBD允许Rados Block Device格式的磁盘挂载到Pod中，同样的，当pod被删除的时候，rbd也仅仅是被卸载，内容保留，rbd能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间“切换”。

cephfs

cephfs Volume可以将已经存在的CephFS Volume挂载到pod中，与emptyDir特点不同，pod被删除的时，cephfs仅被被卸载，内容保留。cephfs能够允许我们提前对数据进行处理，而且这些数据可以在Pod之间“切换”。

提示：可以使用自己的Ceph服务器运行导出，然后在使用cephfs。

gitRepo

gitRepo volume将git代码下拉到指定的容器路径中。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    gitRepo:
      repository: "git@somewhere:me/my-git-repository.git"
      revision: "22f1d8406d464b0c0874075539c1f2e96c253775"

secret

secret volume用于将敏感信息（如密码）传递给pod。可以将secrets存储在Kubernetes API中，使用的时候以文件的形式挂载到pod中，而不用连接api。 secret volume由tmpfs（RAM支持的文件系统）支持。

persistentVolumeClaim

persistentVolumeClaim用来挂载持久化磁盘的。PersistentVolumes是用户在不知道特定云环境的细节的情况下，实现持久化存储（如GCE PersistentDisk或iSCSI卷）的一种方式。

downwardAPI

通过环境变量的方式告诉容器Pod的信息

projected

Projected volume将多个Volume源映射到同一个目录

目前，可以支持以下类型的卷源：

• secret
• downwardAPI
• configMap

所有卷源都要求与pod在同一命名空间中。

示例

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - downwardAPI:
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config
apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

FlexVolume

alpha功能

AzureFileVolume

AzureFileVolume用于将Microsoft Azure文件卷（SMB 2.1和3.0）挂载到Pod中。

AzureDiskVolume

Azure是微软提供的公有云服务，如果使用Azure上面的虚拟机来作为Kubernetes集群使用时，那么可以通过AzureDisk这种类型的卷插件来挂载Azure提供的数据磁盘。

vsphereVolume

需要条件：配置了vSphere Cloud Provider的Kubernetes。有关cloudprovider配置，请参阅vSphere入门指南。

vsphereVolume用于将vSphere VMDK Volume挂载到Pod中。卸载卷后，内容将被保留。它同时支持VMFS和VSAN数据存储。

重要提示：使用POD之前，必须使用以下方法创建VMDK。

创建一个VMDK卷

使用vmkfstools创建。先将ssh接入ESX，然后使用以下命令创建vmdk

vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk

使用vmware-vdiskmanager创建

shell vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk

示例

apiVersion: v1
kind: Pod
metadata:
  name: test-vmdk
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-vmdk
      name: test-volume
  volumes:
  - name: test-volume
    # This VMDK volume must already exist.
    vsphereVolume:
      volumePath: "[DatastoreName] volumes/myDisk"
      fsType: ext4

Quobyte

在kubernetes中使用Quobyte存储，需要提前部署Quobyte软件，要求必须是1.3以及更高版本，并且在kubernetes管理的节点上面部署Quobyte客户端。

PortworxVolume

Portworx能把你的服务器容量进行蓄积（pool），将你的服务器或者云实例变成一个聚合的高可用的计算和存储节点。

PortworxVolume可以通过Kubernetes动态创建，也可以在Kubernetes pod中预先配置和引用。示例：

apiVersion: v1
kind: Pod
metadata:
  name: test-portworx-volume-pod
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /mnt
      name: pxvol
  volumes:
  - name: pxvol
    # This Portworx volume must already exist.
    portworxVolume:
      volumeID: "pxvol"
      fsType: ""

ScaleIO

ScaleIO是一种基于软件的存储平台（虚拟SAN），可以使用现有硬件来创建可扩展共享块网络存储的集群。ScaleIO卷插件允许部署的pod访问现有的ScaleIO卷（或者可以为持久卷声明动态配置新卷，请参阅 Scaleio Persistent Volumes）。

示例：

apiVersion: v1
kind: Pod
metadata:
  name: pod-0
spec:
  containers:
  - image: gcr.io/google_containers/test-webserver
    name: pod-0
    volumeMounts:
    - mountPath: /test-pd
      name: vol-0
  volumes:
  - name: vol-0
    scaleIO:
      gateway: https://localhost:443/api
      system: scaleio
      volumeName: vol-0
      secretRef:
        name: sio-secret
      fsType: xfs

StorageOS

StorageOS是一家英国的初创公司，给无状态容器提供简单的自动块存储、状态来运行数据库和其他需要企业级存储功能，但避免随之而来的复杂性、刚性以及成本。

核心：是StorageOS向容器提供块存储，可通过文件系统访问。

StorageOS容器需要64位Linux，没有额外的依赖关系，提供免费开发许可证。

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: redis
    role: master
  name: test-storageos-redis
spec:
  containers:
    - name: master
      image: kubernetes/redis:v1
      env:
        - name: MASTER
          value: "true"
      ports:
        - containerPort: 6379
      volumeMounts:
        - mountPath: /redis-master-data
          name: redis-data
  volumes:
    - name: redis-data
      storageos:
        # The `redis-vol01` volume must already exist within StorageOS in the `default` namespace.
        volumeName: redis-vol01
        fsType: ext4

Local

目前处于 Kubernetes 1.7中的 alpha 级别。

Local 是Kubernetes集群中每个节点的本地存储（如磁盘，分区或目录），在Kubernetes1.7中kubelet可以支持对kube-reserved和system-reserved指定本地存储资源。

通过上面的这个新特性可以看出来，Local Storage同HostPath的区别在于对Pod的调度上，使用Local Storage可以由Kubernetes自动的对Pod进行调度，而是用HostPath只能人工手动调度Pod，因为Kubernetes已经知道了每个节点上kube-reserved和system-reserved设置的本地存储限制。

示例：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
  annotations:
        "volume.alpha.kubernetes.io/node-affinity": '{
            "requiredDuringSchedulingIgnoredDuringExecution": {
                "nodeSelectorTerms": [
                    { "matchExpressions": [
                        { "key": "kubernetes.io/hostname",
                          "operator": "In",
                          "values": ["example-node"]
                        }
                    ]}
                 ]}
              }'
spec:
    capacity:
      storage: 100Gi
    accessModes:
    - ReadWriteOnce
    persistentVolumeReclaimPolicy: Delete
    storageClassName: local-storage
    local:
      path: /mnt/disks/ssd1

请注意，本地PersistentVolume需要手动清理和删除。

Using subPath

有时，可以在一个pod中，将同一个卷共享，使其有多个用处。volumeMounts.subPath特性可以用来指定卷中的一个子目录，而不是直接使用卷的根目录。

以下是使用单个共享卷的LAMP堆栈（Linux Apache Mysql PHP）的pod的示例。HTML内容映射到其html文件夹，数据库将存储在mysql文件夹中：

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

Resources

emptyDir Volume的存储介质（Disk，SSD等）取决于kubelet根目录（如/var/lib/kubelet）所处文件系统的存储介质。不限制emptyDir或hostPath Volume使用的空间大小，不对容器或Pod的资源隔离。

参考文档：Kubernetes中文文档