Kubernetes 核心概念简介

Kubernets 中的Node, Pod，Replication Controller, Service 等都可以看作一种资源对象，这些资源几乎都可以通过使用Kubernetes提供的kubectl 工具执行增删改查，并将其保存在etcd中持久化储存。通过跟踪对比etcd库中保存的“资源预设状态”与当前环境中的实际资源状态进行对比，对差异资源状态进行纠错，来实现自动控制集群状态的功能。下面将分别介绍这个组件角色。

管理角色

Kubernetes中有两种管理角色，Master和Node.

Master

Master是Kubernetes集群的控制节点，所有对于Kubernetes的命令操作都需要在控制节点执行。Master一般运行如下进程：

kube-apiserver： ?Kubernetes API Server, 提供了HTTP Rest接口的关键服务进程，是所有资源增，删，改，查的入口，也是集群控制的入口进程，kubectl是直接与 API Server交互的，默认监听 6443端口。

kube-controller-manager: 每个资源一般都对应有一个控制器，而controller manager就是负责管理这些控制器的,它是自动化的循环控制器，是Kubernetes的核心控制守护进程。默认监听10252端口。

kube-scheduler ： 负责将pod资源调度到合适的node 上。其本身提供了复杂丰富的调度算法，可以根据node 节点的性能，负载，数据位置等各种情况进行合理的调度。默认监听10251 端口。

etcd: ?一个高可用的键值存储系统，Kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。默认监听2379和2380端口（2379提供服务，2380用于集群节点通信）

Node

除了Master节点，集群中的其它节点被称作Node节点，Node节点是业务应用实际的运行的平台，通过Master 调度不同的任务到Node节点上，以docker 的方式运行。当某个Node节点宕机时，其上的工作负载会被Master自动转移到其它Node节点上。
Node节点上运行着如下进程：

kubelet: Kubelet是在每个Node节点上运行agent,是Node节点上面最重要的模块，它负责维护和管理该Node上面的所有容器，但是Kubelet不会管理不是由Kubernetes创建的容器。本质上，它负责使Pod得运行状态与期望的状态一致。Kubelet会定时向Master汇报自己当前的自身信息，如操作系统，Docker版本，CPU,内存，pod运行状态等信息。

kube-proxy：该模块实现了Kubernetes中的服务发现和反向代理功能。反向代理支持TCP和UDP连接转发，默认基于Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面，kube-proxy使用etcd的watch机制，监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响。

runtime： 这里一般使用docker 容器,Kubernetes也支持其他的容器。

Node节点的状态管理

1、通过在Master查看Node状态：

[root@node-1 ~]# kubectl get nodesNAME ?????STATUS ???ROLES ????AGE ??????VERSIONnode-1 ???Ready ????master ???22h ??????v1.10.2node-2 ???Ready ????<none> ???22h ??????v1.10.2node-3 ???Ready ????<none> ???1h ???????v1.10.2

2、查看Node的详细信息，如下命令会输出节点当前状态的详细信息，包括可用资源总量：

kubectl describe node node-2

Pod

Pod是Kubernetes中非常重要的基本单位。Pod是应用运行的载体,整个Kubernetes系统都是围绕着Pod展开的，比如如何部署运行Pod、如何保证Pod的数量、如何访问Pod等。Pod是一个或多个容器的集合。
在每一个Pod中都有一个特殊的Pause容器和一个或多个业务容器，Pause来源于pause-amd64镜像,Pause容器在Pod中具有非常重要的作用：

• Pause容器作为Pod容器的根容器，其本地于业务容器无关，它的状态代表了整个pod的状态。
• Pod里的多个业务容器共享Pause容器的IP，每个Pod被分配一个独立的IP地址，Pod中的每个容器共享网络命名空间，包括IP地址和网络端口。Pod内的容器可以使用localhost相互通信。k8s支持底层网络集群内任意两个Pod之间进行通信。
• Pod中的所有容器都可以访问共享volumes，允许这些容器共享数据。volumes 还用于Pod中的数据持久化，以防其中一个容器需要重新启动而丢失数据。

Pod 的定义

Kubernetes中所有的资源对象都可以采用YAML或者JSON格式的文件来定义，比如，我们可以定义如下的Pod对象：

apiVersion: v1kind: Podmetadata: ?name: myweb ?labels: ???name: mywebspec: ?containers: ?- name: myweb ???image: kubeguide/tomcat-app:v1 ???ports: ???- containerPort: 8080 ???env: ???- name: MYSQL_SERVER_HOST ?????value: ‘mysql‘ ???- name: MYSQL_SERVER_PORT ?????value: ‘3306‘

2、Pod Volume可以使用分布式文件系统，将Pod Volume定义在Pod上，然后被各个容器挂载到自身的容器。目前Kubernetes支持多种文件存储。

3、我们还可以对pod使用的资源进行配额，一般是对CPU和内存的限制：

apiVersion: v1kind: Podmetadata: ?name: mysql ?labels: ???name: mysqlspec: ?containers: ?- name: db ???image: mysql ???resources: ?????requests: ?????????????????# 最小资源申请量 ???????memory: "64Mi" ????# 64M内存 ???????cpu: "250m" ??????????# 0.25个CPU ?????limits: ??????????????????????# 最大配额 ???????memory: "128Mi" ??# 128M 内存 ???????cpu: "500m" ??????????# 0.5个CPU

4、 Pod 常用操作：

kubectl create -f ?pod_file.yaml ???????????# 创建podkubectl describe pods POD_NAME ?# 查看pod详细信息kubectl get pods ??????????????????????????????# pods 列表kubectl delete pod POD_NAME ???# 删除podkubectl replace ?pod_file.yaml ?????# 更新pod

Label

Label 是用户自定义的键值对，主要是用于标记资源对象，如Node,Pod，Service，RC等。一个资源可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去，Label 通常在资源对象定义时确定，也可以在对象创建后动态的添加或删除。

可以给资源对象绑定多个不同Label,来实现多维度的资源分组管理功能，一些常见的Label示例：

• 版本标签："release":"stable","release":"beta"
• 环境标签：“environment”:"dev" , "environment":"qa" , "environment":"production"

提示：Deployment,ReplicaSet,DaemonSet和Job等管理对象可以在Selector中使用基于集合的筛选条件定义。

Label Selector (标签选择器) ，主要用于对拥有某些Label的资源对象进行查询和筛选，类似SQL的查询机制。
Label Selector可以通过基于等式和集合的查询方式进行匹配查询，通过多个表达式的组合，从而实现复杂的条件选择，如：

name=mysql,env!=productionname notin (tomcat),env!=production

Replication Controller

Replication Controller（RC）是Kubernetes中的另一个核心概念，Kubernetes中通过RC来保证应用能够持续运行，它会确保任何时间Kubernetes中都有指定数量的Pod处于运行状态。在此基础上，RC还提供了一些更高级的特性，比如滚动升级、升级回滚等。

RC在Kubernetes中定义了一个期望的场景，即声明某种pod副本数量在任意时刻符合某个预期的值，其定义的内容如下：

• Pod 期待的副本数（replicas）
• 用于筛选目标Pod的Label Selector.
• 当Pod 的副本数量小于预期的数量时，用于创建新的Pod

RC运行过程： ?当我们定义了一个RC的YAML文件（或者调用kubectl命令）提交到Kubernets集群后，Master 上的Controller Manager组件就得到通知，定期巡检系统中当前存活的目标Pod,并确保目标Pod实例的数量刚好邓毅此RC的期望值。如果有过多的Pod副本在运行，系统就会停掉一些Pod,反之则会自动创建一些Pod。

自动伸缩

通过修改RC数量，实现Pod的动态缩放：

kubectl scale rc myweb --replicas=10 ???????# 将pod 扩展到10个 ??????kubectl scale rc myweb --replicas=1 ?????????# 将pod 缩到 1个

滚动升级

使用RC可以进行动态平滑升级,保证业务始终在线。其具体实现方式：

 kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s

升级开始后，首先依据提供的定义文件创建V2版本的RC，然后每隔10s（--update-period=10s）逐步的增加V2版本的Pod副本数，逐步减少V1版本Pod的副本数。升级完成之后，删除V1版本的RC，保留V2版本的RC，及实现滚动升级。

升级过程中，发生了错误中途退出时，可以选择继续升级。Kubernetes能够智能的判断升级中断之前的状态，然后紧接着继续执行升级。当然，也可以进行回退，命令如下：

 kubectl rolling-update my-rcName-v1 -f my-rcName-v2-rc.yaml --update-period=10s --rollback

ReplicaSet

replica set，可以被认为 是“升级版”的Replication Controller。replica set也是用于保证与label selector匹配的pod数量维持在期望状态。区别在于，replica set引入了对基于子集的selector查询条件，而Replication Controller仅支持基于值相等的selecto条件查询。replica set很少被单独使用，目前它多被Deployment用于进行pod的创建、更新与删除的编排机制。

RC（Replica Set）特性和作用

• 通过定义一个RC实现Pod的创建过程及副本数量的自动控制。
• RC 里包括完整的Pod定义模板。
• RC通过Label Selector 机制是对Pod副本的自动控制。
• 通过改变RC的副本数量，可以实现Pod副本的扩容和缩容。
• 通过改变RC里Pod模板中的镜像版本，可以实现Pod滚动升级。

Deployment

Deployment主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。Deployment内部使用了Replica Set来实现。
Deployment 相对于RC一个最大的升级是我们可以随时知道当前Pod "部署"的进度，和详细的运行状态。
具有以下使用场景：

创建Pod: 可以创建一个Deployment对象来生成对应的Replica Set,完成Pod副本的创建。
查看事件状态： 通过检查Deployment的状态来查看部署动作是否完成，如副本数量是否达到了预期的值。
升级：更新Deployment以创建新的Pod,同时还可以清理不再需要的旧版本ReplicaSet。
回滚： 如果当前的Pod不稳定或者有bug,可以回滚到一个早期的稳定版本。
暂停和恢复：可以随时暂停Deployment对象，修改对应的参数配置，之后再恢复Deployment继续发布。

Deployment 定义

Deployment的定义和Replica Set的定义几乎一样，仅仅是API版本和kind类型不同：

# Deployment的声明apiVersion: apps/v1kind: Deploymentmetadata: ?name: nginx-deployment ?labels: ???app: nginxspec: ?replicas: 3 ?selector: ???matchLabels: ?????app: nginx ?template: ???metadata: ?????labels: ???????app: nginx ???spec: ?????containers: ?????- name: nginx ???????image: nginx ???????ports: ???????- containerPort: 80# Replica Set的声明apiVersion: v1kind: ReplicaSetmetadata: ?name: mysql...

创建一个deployment

1、这里以上面的nginx为例，创建nginx：

[root@node-1 ~]# kubectl create -f nginx.yaml deployment.apps "nginx-deployment" created

2、查看Deployment信息：

# 刚执行时，显示的AVAILABLE数量时0[root@node-1 ~]# kubectl get deploymentsNAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????3 ????????3 ???????????0 ??????????22s# 1分钟后显示已经有3个可用nginx-deployment[root@node-1 ~]# kubectl get deploymentsNAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????3 ????????3 ???????????3 ??????????1m# 查看pods[root@node-1 ~]# kubectl get pods | grep nginxnginx-deployment-666865b5dd-cfmfp ??1/1 ??????Running ??0 ?????????11mnginx-deployment-666865b5dd-nhxtv ??1/1 ??????Running ??0 ?????????11mnginx-deployment-666865b5dd-qj7sf ??1/1 ??????Running ??0 ?????????11m# 查看 rs[root@node-1 ~]# kubectl get rsNAME ?????????????????????????DESIRED ??CURRENT ??READY ????AGEnginx-deployment-666865b5dd ??3 ????????3 ????????3 ????????25m# 查看deployments的详细部署信息[root@node-1 ~]# kubectl describe deployments...

对于上述kubectl get deployments的输出，其含义：

• DESIRED : Pod副本数量的期望值，即Deployment里定义的Replica。
• CURRENT： 当前实际的Replica数量，当这个值不断增加，达到DESIRED时表明部署完成。
• UP-TO-DATE：最新版本的Pod副本数量，用于指示在滚动升级过程中有多少Pod副本已经成功升级。
• AVAILABLE: 当前集群中可用的Pod副本数量（当前存活的Pod数量）

使用kubectl describe deployments命令可以获取指定Deployment的详细状态

滚动升级

例如，我们要对当前的nginx-deployment进行升级或者回滚，可以使用如下两种方式。

* ?直接 set 镜像

1、若要对docker镜像进行更新，直接 set 镜像：

[root@node-1 ~]# kubectl set image deployment/nginx-deployment nginx=nginx:1.12.2

2、查看状态，可以发现在保证pod 可用的状态下，会平滑的替换旧的deployment对象，并且会记录此过程：

[root@node-1 ~]# kubectl ?get deploymentsNAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????4 ????????1 ???????????3 ??????????3h[root@node-1 ~]# kubectl ?get deploymentsNAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????4 ????????2 ???????????3 ??????????3h[root@node-1 ~]# kubectl ?get deploymentsNAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????3 ????????3 ???????????3 ??????????4h[root@node-1 ~]# kubectl get rsNAME ?????????????????????????DESIRED ??CURRENT ??READY ????AGEnginx-deployment-666865b5dd ??0 ????????0 ????????0 ????????4hnginx-deployment-69647c4bc6 ??3 ????????3 ????????3 ????????3m[root@node-1 ~]# kubectl describe deployments ??# 会显示详细events事件

* 直接edit Deployment

1、执行 edit命令修改Deployment配置，类似KVM的virsh edit 命令，修改后立即生效(如果没有修改，将不会发生任何变化)：

[root@node-1 ~]# kubectl edit deployments/nginx-deployment

2、查看deployment状态：

[root@node-1 ~]# kubectl get deployments NAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????4 ????????1 ???????????3 ??????????5h[root@node-1 ~]# kubectl get deployments NAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????4 ????????3 ???????????3 ??????????5h[root@node-1 ~]# kubectl get deployments NAME ??????????????DESIRED ??CURRENT ??UP-TO-DATE ??AVAILABLE ??AGEnginx-deployment ??3 ????????3 ????????3 ???????????3 ??????????5h

3、一般常见的修改是修改镜像版本和参数。

回滚

1、执行回滚命令，到上一个版本：

[root@node-1 ~]# kubectl rollout undo deployment/nginx-deployment

2、使用如下命令，可以查看保存的deployment历史：

[root@node-1 ~]# kubectl get rsNAME ?????????????????????????DESIRED ??CURRENT ??READY ????AGEnginx-deployment-666865b5dd ??0 ????????0 ????????0 ????????5hnginx-deployment-68dfb7c95b ??3 ????????3 ????????3 ????????27mnginx-deployment-69647c4bc6 ??0 ????????0 ????????0 ????????1h

命令参考

• kubectl describe deployments ?#查询详细信息，获取升级进度
• kubectl get deployments ?# 获取升级进度的简略信息
• kubectl get rs ????????# 获取RS记录，每执行一次deployment就会生成一个RS记录。
• kubectl set image deployment/nginx-deployment nginx=nginx:1.12.2 ?# 升级
• kubectl edit ?deployments/nginx-deployment ?# 修改deployment 参数
• kubectl rollout pause deployment/nginx-deployment ??#暂停升级
• kubectl rollout resume deployment/nginx-deployment ??#继续升级
• kubectl rollout undo deployment/nginx-deployment ??#回滚到上一版本
• kubectl scale deployment nginx-deployment --replicas 10 ?#弹性伸缩Pod数量

Service

Service是Kubernetes中的核心对象之一。Kubernetes中的Pod,RC,等资源对象最终都是为Service服务。
Service定义了一个服务访问的入口地址，前端应用Pod通过这个地址访问后端的Pod集群实例，Service通过Label Selector来实现与后端Pod集群的通讯。其中，RC的作用是保障集群中始终有可用的Pod集群，从而确保了服务质量。

Service原理

Service的服务原理图：

在上图中，我们需要理解以下几点：

• Service其实就是一个对外的服务接口，当我们创建一个service时，k8s会自动创建一个全局唯一的Cluster IP,这个IP是一个虚拟的IP，如果尝试使用PING是无法ping通的，但是，它是连通前端Pod和后端服务Pod的桥梁，虽然不能ping通，但是可以通过IP+端口的方式访问后端Pod。后端的Pod组成了一个集群，通过RC的控制来提供永不间断的服务。
• 在Service的整个生命周期内，Cluster IP不会发生改变，Service Name与Cluster IP形成固定的映射关系（这里一般使用的是DNS，早期使用的是环境变量的方式），这样就不存在服务发现的问题。

• Service的Cluster IP和Endpoint属于Kubernetes集群内部的地址，无法在集群外部使用,一般会使用Flannel、Weave、Romana等第三方网络服务来实现Pod之间的通讯。这里涉及网络的部分我们会在后续的博文中单独讨论。

• Kubernetes在每个Node节点上都运行着一个kube-proxy的进程，它扮演了负载均衡器的角色，它负责将对service的请求转发到后端的某个Pod实例上，并在内部实现了负载均衡和会话保持的机制。

外部访问Service

由于Cluster IP是一个内部地址，外部的node 节点无法直接访问到，当我们的外部用户需要访问这些服务时，需要在定义Service时添加NodePort的扩展。下面的文件定义了一个nginx服务添加外部NodePort的示例。
编辑service文件：

apiVersion: v1kind: Servicemetadata: ??name: nginxspec: ?type: NodePort ?ports: ???- port: 80 ?????nodePort: 30008 ??# 对外的用户访问端口，默认范围是30000-32767 ?selector: ???app: nginx

当我们创建这个service后，所有的节点上都会有30008的端口映射，访问任意节点都会转发到对应的Pod集群中。

命令参考

• kubectl get services ???????????????????# 获取service列表，可以指定具体的service
• kubectl describe services ??????????# 显示service的详细信息，可以指定具体的service
• kubectl get endpoints ?????????????????# 获取Endpoint 信息
• kubectl delete services mysql ?????# 删除指定的service

Volume

在Kubernetes中，Volume是能被Pod中多个容器访问的共享目录。由于Pod中的容器随时可能会被销毁或重建，对于一些需要数据共享或要持久化保存的数据，我们需要使用单独的存储空间，挂载到对应的Pod上。当容器终止时，Volume中的数据不会丢失。

Volume的定义格式：

apiVersion: v1kind: Podmetadata: ?name: test-pdspec: ?containers: ?- image: k8s.gcr.io/test-webserver ???name: test-container ???volumeMounts: ???- mountPath: /cache ?????name: cache-volume ?volumes: ?- name: cache-volume ???emptyDir: {} ???????????????????# 指定Volume类型

Kubernetes支持多种类型的Volume,下面会对一些常见的Volume做出说明。

本地存储

• emptyDir: 无需指定宿主机的对应目录路径，由Pod自动创建，Pod移除时数据会永久删除，作为容器间的共享目录。上面的示例就是此格式的Volume。
• hostPath: Pod挂载宿主机上的文件和目录，可用于永久保存日志，容器内部访问宿主机数据，定义方式如下：

  apiVersion: v1kind: Podmetadata:name: test-pdspec:containers:- image: k8s.gcr.io/test-webservername: test-containervolumeMounts:- mountPath: /test-pd ?name: test-volumevolumes:- name: test-volumehostPath: ?# directory location on host ?path: /data ?# this field is optional ?type: Directory

网络存储

• gce Persistemt Disk: ?谷歌公有云提供的永久磁盘，这里要求使用谷歌的公有云，节点是GCE虚拟机才行。
• AWS Elastic Block Store： 与GCE类似，此类型的Volume使用亚马逊公有云提供的EBS数据存储。
• NFS： NFS网络文件系统的数据存储，这个需要部署NFS服务器，定义如下：

volumes: ?- name: nfs ???nfs: ?????????server: NFS-SERVER-IP ??# NFS 服务器地址 ???????????path: "/"

• iscsi： 使用iSCSI存储设备上的目录挂载到Pod中。
• glusterfs： 使用GlusterFS挂载到Pod中。
• rbd： 使用Ceph对象存储挂载到Pod。
  除此之外，Kubernetes还支持其他的存储方式，具体详情可以查看官方文档。

Persistent Volume

理解并管理五花八门的存储是一件让人头疼的事情，Kubernetes为了解决这些问题，对所有的网络存储进行了抽象，让我们在管理这些存储时不必考虑后端的实现细节，对于不同的网络存储统一使用一套相同的管理手段。
PersistentVolume为用户和管理员提供了一个API，它抽象了如何提供存储以及如何使用它的细节。 为此，引入两个新的API资源：PersistentVolume和PersistentVolumeClaim。
PersistentVolume（PV）: 是管理员设置的单独的网络存储集群，它不属于任何节点，但是可以被每个节点访问。 PV是Volumes之类的卷插件，具有独立于的生命周期。 此API对象用于捕获存储实现的细节，如NFS，iSCSI，GlusterFS,CephFS或特定于云提供程序的存储系统。
PersistentVolumeClaim（PVC）：是用户对存储的请求的定义。 它与pod相似。pods消耗节点资源，PVC消耗PV资源， Pods可以请求特定级别的资源（CPU和内存）。Claim可以配置特定的存储资源大小和访问模式（例如，多种不同的读写权限）,并根据用户定义的需求去使用合适的Persistent Volume。

定义Persistent Volume

apiVersion: v1kind: PersistentVolumemetadata: ?name: pv1spec: ?capacity: ???storage: 5Gi ?accessModes: ???- ReadWriteOnce ?nfs: ???path: /somepath ???server: 10.2.2.2

accessModes有三种权限：

• ReadWriteOnce：读写权限，只能被单个Node挂载
• ReadOnlyMany: 只读权限，允许被多个Node挂载
• ReadWriteMany: 读写权限、允许被多个Node挂载。

定义Persistent Volume Claim

如果某个Pod想申请某种类型的PV，可以做如下定义：

apiVersion: v1kind: PersistentVolumeClaimmetadata: ?name: myclaimspec: ?accessModes: ???- ReadWriteOnce ?resources: ???requests: ?????stroage: 8Gi

定义之后再Pod的Volume中引用上述PVC：

volumes: ?- name: mypd ???persistentVolumeClaim: ?????????claimName: myclaim

PV的状态

PV是有状态的对象，有如下几种状态：

• Available: 空闲状态
• Bound: 已经绑定到某个PVC上
• Released: 对应的PVC已经删除，但是资源还没有被释放
• Failed: PV自动回收失败

Namespace

Namespace(命名空间)是Kubernetes中非常重要的概念，Namespace在很多情况下实现多租户的资源隔离，将集群中的不同资源对象分配到不同的Namespace中，形成逻辑上分组的不同项目，便于不同分组在使用集群资源的同时还能被分别管理。
Kubernetes在启动之后，默认会创建一个default的Namespace:

[root@node-1 ~]# kubectl get namespacesNAME ?????????STATUS ???AGEdefault ??????Active ???3d

当我们创建对象时，不指定namespace就会使用默认的default:

[root@node-1 ~]# kubectl get pods --all-namespacesNAMESPACE ????NAME ???????????????????????????????READY ????STATUS ???RESTARTS ??AGEdefault ??????mysql-fw2pj ????????????????????????1/1 ??????Running ??2 ?????????1ddefault ??????myweb-4jk8j ????????????????????????1/1 ??????Running ??2 ?????????1ddefault ??????myweb-68zfl ????????????????????????1/1 ??????Running ??2 ?????????1ddefault ??????myweb-bv8pt ????????????????????????1/1 ??????Running ??2 ?????????1ddefault ??????nginx-deployment-68dfb7c95b-6zcj4 ??1/1 ??????Running ??2 ?????????1ddefault ??????nginx-deployment-68dfb7c95b-g89nd ??1/1 ??????Running ??3 ?????????1ddefault ??????nginx-deployment-68dfb7c95b-zvtkf ??1/1 ??????Running ??2 ?????????1dkube-system ??etcd-node-1 ????????????????????????1/1 ??????Running ??7 ?????????3d ...

Namespace的定义

使用yaml文件定义一个名为deployment的Namespace:

apiVersion: v1kind: Namespacemetadata: ?name: deployment

当创建对象时，就可以指定这个资源对象属于哪个Namespace:

apiVersion: v1kind: Podmetadata: ?name: myweb ?namespace: development

当我们指定非默认的namespace之后，使用如下命令就只能查看默认区域的namespaces:

# kubectl get pods

查看所有namespace区域的对象要使用--all-namespaces参数：

# kubectl get pods --all-namespaces#也可以指定namespaces:# kubectl get pods --namespace=kube-system

Horizontal Pod Autoscaler

HPA与之前介绍的RC，deployment一样，也是属于Kubernetes的一种资源对象。HPA通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否需要针对性的调整目标Pod的副本数。HPA有以下两种方式来度量Pod的负载情况：

• CPU Utilization Percentage: CPU利用率百分比
• 自定义的度量指标

CPU的利用率百分比通常是度量的Pod CPU 1min内的平均值，使用Heapster扩展组件来得到这个值，这里定义一个简单的例子：

apiVersion: autoscaling/v1kind: HorizontalPodAutoscalermetadata: ?name: myweb ?namespace: defaultspec: ?maxReplicas: 10 ?minReplicas: 2 ?scaleTargetRef: ???kind: Deployment ???name: myweb ?targetCPUUtilizationPercentage: 90

当Pod 副本的CPU利用率超过90%时会触发自动扩容行为，且Pod数量最多不能超过10，最少不能低于2.
除此之外，也可以使用命令操作：

kubectl autoscale deployment myweb ?--cpu-percent=90 --min=1 --max=10

StatefulSet

在Kubernetes系统中，Pod管理的对象如 RC，Deployment,DaemonSet 和Job 都是面向无状态的服务。对于无状态的服务我们可以任意销毁并在任意节点重建，但是在实际的应用中，很多服务是有状态的，特别是对于复杂的中间件集群，如Mysql集群，MongoDB集群，Zookeeper集群，etcd集群等，这些服务都有固定的网络标识，并有持久化的数据存储，这就需要使用StatefulSet对象。
StatefulSet具有以下特性：

• StatefulSet里的每个Pod都有稳定且唯一的网络标识， 可以用来发现网络中的其他成员。
• StatefulSet 控制的Pod副本的启停顺序是受控的，比如操作第n个Pod时，前n-1个Pod必须是正常运行的状态。
• Pod 采用稳定的持久化存储卷，删除Pod时默认不会删除与StatefulSet相关的储存卷。

参考资料：
https://kubernetes.io/docs/concepts/
https://www.cnblogs.com/zhenyuyaodidiao/p/6500720.html
《Kubernets权威指南》

Kubernetes 核心概念简介

原文地址：http://blog.51cto.com/tryingstuff/2119034