在Kubernetes，当配置Pod时，可以为每一个容器设置CPU和内存这些计算资源。当容器被指定资源请求后，调度器将能够更好的决定将Pod部署在那一个Node上。

1、资源类型

在当前的Kubernetes版本中，计算资源有CPU和内存这两种类型。CPU的基本单位是核(Core)，内存的基本单位是字节(byte)。CPU和内存统称为“计算资源”。在Kubernetes中，计算资源是可以被请求、分配和消耗的可测量的数量。

Pod中的每一个容器都能够通过如下的方式设置CPU和内存的资源：

• spec.containers[].resources.limits.cpu
• spec.containers[].resources.limits.memory
• spec.containers[].resources.requests.cpu
• spec.containers[].resources.requests.memory

虽然从根源上来说，requests和limits是在容器上进行设置的，但是在Pod级别上的设置会带来更大的便利。Pod上的request/limit是Pod中各个容器request/limit的总和。

1.1 CPU资源

在Kubernetes中CPU资源通过cpu数量进行计算。如果容器的spec.containers[].resources.requests.cpu值为0.5，则表示它需要半个cpu。在Kubernetes中，如果spec.containers[].resources.requests.cpu值为0.1，则等价于spec.containers[].resources.requests.cpu值为100m。在kubernetes，设置CPU资源时，最小值为1m，也就是0.001。CPU资源是一个绝对值，而不是相对值，因此在单核，双核或者48核机器上，0.1都表达是同一意思，即0.1个CPU core。

1.2 内存资源

在Kubernetes中，内存资源的计算单位为字节数(byte)，可以直接使用整型数字表达，也可以使用整数加国际单位制来表示。国际单位制包括：十进制(E, P, T, G, M, K)和二进制(Ei, Pi, Ti, Gi, Mi, Ki)，其中：1KB(kilobyte)=1000bytes，1KiB(kibibyte)=2^10bytes=1024bytes。例如，以下代表大致相同的值：

128974848, 129e6, 129M, 123Mi

1.3 示例

下面的例子中拥有两个容器的Pod，每一个容器的request是0.25 cpu和 64MiB 内存，每个容器的limit是0.5 cpu和128MiB 内存。因此，Pod的requst是0.5核cpu和128MiB内存，Pod的limit是1核cpu和256MiB内存。

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

2、基于资源的Pod调度

在创建一个Pod时，Kubernetes调度器将会为Pod选择一个运行的Node。对于每一个Node来说，其都存在一个最大的资源能力(CPU和内存)。调度器在调度时，要确保Node上CPU和内存能够满足所有Pod对于计算资源的要求。

当kubelet启动Pod中的容器时，它会将容器的request和limit作为参数传递给容器运行时。如果容器运行时使用的是docker：

• spec.containers[].resources.requests.cpu的值会被转换为core，然后乘以1024，再将结果通过–cpu-shares参数的值传递给docker run命令。
• spec.containers[].resources.limits.cpu的值会被转化为millicore，然后乘以100。结果值是作为容器在100微秒内能够使用的CPU总量时间。默认的配额周期是100ms，最小的CPU配额是1ms。
• spec.containers[].resources.limits.memory被转化为整数，在docker run命令中作为–memory字段的值。

如果容器在运行过程中使用的内存超过了内存的limit，它将会被终止。同时如果此容器是可重启的，则kubelet会在后续会重新启动它。如果容器在运行过程中使用的内存超过了内存的request，则当Node内存不足时，它所在的Pod会被删除。

与内存不同的是，在容器运行过程中如果使用了超过要求CPU，容器并不会被杀死。

3、监控计算资源使用情况

在Kubernetes中，计算资源的使用情况作为Pod状态信息的一部分被报告。另外，如果已经在集群中配置了监控，也可以通过监控系统获取Pod的资源使用情况。

4、问题处理

4.2 Pod的状态为pending，事件信息为failedScheduling

如果调度器无法为Pod找到合适的Node，则Pod会一直处于未调度的状态。通过执行下面的命令能够查看信息：

$ kubectl describe pod frontend | grep -A 3 Events
Events:
  FirstSeen LastSeen   Count  From          Subobject   PathReason      Message
  36s   5s     6      {scheduler }              FailedScheduling  Failed for reason PodExceedsFreeCPU and possibly others

在上面的例子中，Pod名称为fronted，由于Node的CPU资源不足，导致其无法被调度。同一如果内存不足的话也会导致Pod无法被调度。这里错误的解决方案如下：

• 往集群中添加新的Node；
• 终止不需要的Pod释放资源，以为处于pengding状态的Pod提供资源；
• 检查Pod的配置，以保证Pod的资源要求不超过Node提供资源最大值。例如，如果集群中所有的Node只提供了1核的CPU，如果Pod需要1.1核的CPU，则Pod将无法被调度。

通过执行如下的命令可以检查Node所提供的计算资源：

$ kubectl describe nodes e2e-test-minion-group-4lw4
Name:            e2e-test-minion-group-4lw4
[ ... lines removed for clarity ...]
Capacity:
 cpu:                               2
 memory:                            7679792Ki
 pods:                              110
Allocatable:
 cpu:                               1800m
 memory:                            7474992Ki
 pods:                              110
[ ... lines removed for clarity ...]
Non-terminated Pods:        (5 in total)
  Namespace    Name                                  CPU Requests  CPU Limits  Memory Requests  Memory Limits
  ---------    ----                                  ------------  ----------  ---------------  -------------
  kube-system  fluentd-gcp-v1.38-28bv1               100m (5%)     0 (0%)      200Mi (2%)       200Mi (2%)
  kube-system  kube-dns-3297075139-61lj3             260m (13%)    0 (0%)      100Mi (1%)       170Mi (2%)
  kube-system  kube-proxy-e2e-test-...               100m (5%)     0 (0%)      0 (0%)           0 (0%)
  kube-system  monitoring-influxdb-grafana-v4-z1m12  200m (10%)    200m (10%)  600Mi (8%)       600Mi (8%)
  kube-system  node-problem-detector-v0.1-fj7m3      20m (1%)      200m (10%)  20Mi (0%)        100Mi (1%)
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  CPU Requests    CPU Limits    Memory Requests    Memory Limits
  ------------    ----------    ---------------    -------------
  680m (34%)      400m (20%)    920Mi (12%)        1070Mi (14%)

4.2 容器被终止

如果应用资源的原因，容器被强行终止。可以通过执行下面的命令来检查导致容器终止的原因

[12:54:41] $ kubectl describe pod simmemleak-hra99
Name:                           simmemleak-hra99
Namespace:                      default
Image(s):                       saadali/simmemleak
Node:                           kubernetes-node-tf0f/10.240.216.66
Labels:                         name=simmemleak
Status:                         Running
Reason:
Message:
IP:                             10.244.2.75
Replication Controllers:        simmemleak (1/1 replicas created)
Containers:
  simmemleak:
    Image:  saadali/simmemleak
    Limits:
      cpu:                      100m
      memory:                   50Mi
    State:                      Running
      Started:                  Tue, 07 Jul 2015 12:54:41 -0700
    Last Termination State:     Terminated
      Exit Code:                1
      Started:                  Fri, 07 Jul 2015 12:54:30 -0700
      Finished:                 Fri, 07 Jul 2015 12:54:33 -0700
    Ready:                      False
    Restart Count:              5
Conditions:
  Type      Status
  Ready     False
Events:
  FirstSeen                         LastSeen                         Count  From                              SubobjectPath                       Reason      Message
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {scheduler }                                                          scheduled   Successfully assigned simmemleak-hra99 to kubernetes-node-tf0f
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   pulled      Pod container image "k8s.gcr.io/pause:0.8.0" already present on machine
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   created     Created with docker id 6a41280f516d
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    implicitly required container POD   started     Started with docker id 6a41280f516d
  Tue, 07 Jul 2015 12:53:51 -0700   Tue, 07 Jul 2015 12:53:51 -0700  1      {kubelet kubernetes-node-tf0f}    spec.containers{simmemleak}         created     Created with docker id 87348f12526a

在上面的例子中，Restart Count: 5显示了Pod中的容器simmemleak被终止和重启了5次。

可以通过带-o go-template=…参数的kubectl get pod 命令获取已终止容器的状态信息：

[13:59:01] $ kubectl get pod -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}'  simmemleak-hra99
Container Name: simmemleak
LastState: map[terminated:map[exitCode:137 reason:OOM Killed startedAt:2015-07-07T20:58:43Z finishedAt:2015-07-07T20:58:43Z containerID:docker://0e4095bba1feccdfe7ef9fb6ebffe972b4b14285d5acdec6f0d3ae8a22fad8b2]]

通过输出的信息，可以看出是由于reason:OOM Killed的原因，导致了容器被终止，这里的OOM代表Out Of Memory。

参考资料

1.《Managing Compute Resources for Containers》地址：https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

近日，阿里巴巴揭露了内部架构全面容器化的历程，目前阿里巴巴和蚂蚁金服集团多数事业部门，都已经采用了阿里巴巴去年11月开源的企业级容器平台PouchContainer，这套平台也遵循开源容器标准OCI，可与Docker兼容。阿里巴巴透露，去年双11购物节也是靠PouchContainer才撑过爆量交易的需求，高峰期启动了超过百万个容器来执行交易程序。PouchContainer也针对不同应用场景所需的容器配置进行优化，包括了电商平台、数据库、串流计算、大数据分析等。目前PouchContainer也刚于9月正式发布了1.0版。
阿里巴巴指出，PouchContainer和其他容器平台最大不同是，特别考虑了后续维运的需求，在隔离、镜像推送优化、丰富容器模式、扩充性和核心兼容性（兼容于Docker、Kubernetes等）都有强化。

Windows Server 2019正式版来了，支持Kubernetes和Linux容器

微软新版企业级操作系统Windows Server 2019正式版正式在10月出炉，主打四大特色，包括了混合云、安全、应用程序平台及超融合基础架构。还新增了以浏览器为基础的服务器管理套件Windows Admin Center（1809版），可支持私有云和Azure的混合云应用架构，更容易将既有的Windows Server部署，连结至云端的Azure服务。而System Center 2019则要等到明年上半年才问世。

另外，在应用平台功能上，Windows Server 2019也将Server Core的容器镜像大小，也从5GB缩减了三分之一，以加速镜像的下载，并改善程序的兼容性，也支持Service Fabric、Kubernetes与Linux容器。另外在超融合基础架构部署上，新版也从过去只支持2个节点，增加到可部署到100个服务器的规模。微软也同时宣布将在2020年终止支持旧版的Windows Server 2008和Windows Server 2008 R2。

参考：https://www.ithome.com.tw/news/126430

https://www.ithome.com.tw/news/126431

在容器商用化市场竞赛上，Docker以简单易用的封装设计，掀起了容器技术的浪潮，相继成为了容器技术的标准，也带动了IT架构下个十年的变革。

虽然早在2006年就开始发展容器技术的Google慢了一步，但每周至少启用20亿个容器的大规模部署经验，让Google走上了另一条容器发展之路，也就是以提供大规模容器调度和集群管理为主的Kubernetes计划。

4年过去了，Docker和Kubernetes的地位显然互换，过去Docker是最多人琅琅上口的容器技术名词，现在主角则变成了Kubernetes。云端教父AWS云端架构策略副总裁Adrian Cockcroft曾指出，两者虽然都是运用容器技术，但最大的差异是，Docker是要解决应用程序开发（Developing）问题，而Kubernetes是要解决更上层的应用程序运维问题（Operation）。开发问题是早期的痛点，但随着企业越来越依赖容器技术，内部应用越来越多是云原生应用时，运维会是企业IT的新痛点。

运维管理需求是Kubernetes后来居上的关键

因为云原生应用大多采用微服务架构设计，结合容器技术，一支应用程序往往需要数十，甚至复杂者要上百个容器化微服务程序组成，企业若有1百支应用，就得管上数千，甚至上万个容器化微服务，运维管理就成了最大的挑战。这正是后来主打大规模容器集群管理的Kubernetes后来胜出的关键。

企业商软大厂也纷纷加入Kubernetes平台战局，不论是在云端服务或是私有PaaS平台上，来发展自己的Kubernetes产品。像微软更直接找来Kubernetes共同创办人Brendan Burns，负责率领Azure容器服务团队，自己混合云产品Azure Stack也大力支持Kubernetes。IBM同样也靠以Kubernetes为核心的PaaS软件IBM Cloud Private，要来抢攻企业私有云容器平台市场，尤其是微服务管理需求。

很早就支持Kubernetes的红帽，在2015年推出的OpenShift 3.0版中，不惜放弃自己的容器调度工具，开始支持Kubernetes，现在更成为了要通吃跨多云、混合云架构，又能通吃裸机、容器和VM的企业级通用应用管理平台。而虚拟化龙头VMware也不落人后，近来也改力推主打通吃多家IaaS公云和Kubernetes集群管理的容器服务PKS软件。连甲骨文都在旗下云端服务支持Kubernetes。

而云端容器托管服务这两年更进入了新的竞争阶段，不少云端业者相继将自己容器托管服务中的Container，改由Kubernetes取代，例如Azure的ACS早在去年就换成了AKS， IBM则是今年5月将Cloud Container Service更名为Cloud Kubernetes Service，简称IKS。Kubernetes取代了Container，成了容器服务的新代名词。

Google计划先让Helm格式成为Kubernetes App封装格式

但是，Google的Kubernetes布局，迟迟没有跨出云端，除了积极参与Kubernetes开源项目之外，就是全力发展GKE，试图打造出云端容器代管服务领导者的地位。直到今年Next云端产品大会举办前一周，Google低调地发布了一个消息，将原本GCP的服务快速安装入口网站（Cloud Launcher）更名为Google Cloud应用市场，开始卖起来各种第三方软件厂商开发的商业软件。

其中最特别的是，这个App市场中设置了企业级Kubernetes App类型，也就是Kubernetes App市场。使用GCP的企业，可以直接在这个App市场，购买想要用的Kubernetes App。Nginx、Spark、Elasticsearch、WordPress、Cassandra等13家软件公司，开始透过Kubernetes App的形式销售企业级软件。

Google还预告要制订一个Kubernetes App的标准，就像OCI容器镜像那样的容器应用打包形式，Google试图要让通过Kubernetes封装管理套件Helm打包的Kubernetes App也能成为一种流通用的封装格式。

不同Docker容器化应用，得将所有程序封装到单一个镜像中，Helm可以将组合一支应用系统的多个微服务程序各自的镜像，打包到一套应用程序包中封装，更符合大型企业应用或复杂云端原生应用的需求。

和Helm封装形式的通用化和专用市场形式的出现，让Kubernetes App成了容器化应用的新格式，这是Google新一代AP层的成形，打下第一个基础。

GKE On-Prem主机首次公开

到了Next大会第一天开场演讲中，正当Google现场示范如何管理部署在两地的GKE容器集群时，突然秀出其中一套GKE的部署地点，竟然就在Next大会举办地点Moscone Center。随即，舞台上也出现了这台GKE主机，Google Cloud云端基础架构资深副总裁Urs Hölzle当场宣布，云端GKE服务将推出软件版本GKE On-Prem，可安装于企业内部机房服务器中。

Urs Hölzle宣布，Google将以GKE On-Prem软件，搭配开源微服务管理平台Istio，组成一套混合云软件称为Cloud Services Platform。GKE On-Prem的管理接口和云端GKE服务完全相同，企业可以将云端GKE上的服务，搬到自己机房，而不用改变管理运维方法。企业运维人员通过Google Cloud Console就可以同时管理云端的GKE服务和部署于自己机房的GKE On-Prem环境。

而Istio则是一套采取服务网格（Service Mesh）架构，来管理大量微服务的软件，可以将多个Kubernetes集群，集中到单一套服务网格中，来管理，并能支持跨Kubernetes集群联机，也能确保每个集群都套用一致的管理政策。不只Google，红帽同样也在自己的OpenShift上要支持Istio，同样都是看上企业未来大量微服务管理的需求。

不只如此，GKE On-Prem软件也强化了多项混合云整合机制，如企业可使用也可和云端GKE整合，不用建立复杂VPN。另外也可通用云端身份或自己的身份验证服务来登入GKE On-Prem。

运算工作可以跨不同GKE云端集群或自家的GKE集群间移动。企业可自建一个本地端Prometheus来监控GKE On-Prem，也可用云端的Stackdriver服务来监控本地端的GKE On-Prem集群。

不同于云端GKE，本地端GKE软件可存取持久性储存服务来部署大型应用，例如复杂的数据库。Google云端部署工具Cloud Build也可用来部署本地端GKE On-Prem上的容器应用。而Kubernetes应用市场上的Kubernetes应用，果不其然，也可部署到本地端的GKE On-Prem环境中。

Google的Cloud Services Platform战略布局，不只是涵盖了混合云、企业私有云、Kubernetes App市场，还要让自家无服务器服务，能部署到GKE On-Prem上，来进入企业内部。

Google企业混合云架构的最后一块拼图

Urs Hölzle表示，Kubernetes已经成为企业基础架构的部署标准之一，也因此，Google现在更进一步要用GKE On-Prem软件来补齐企业混合云架构的最后一块拼图。Google新策略是将云带到你身边。要让企业内部环境（on premise）到云端环境的管理工具能一致化，从网络到应用程序都能用同样的管理方式。

而他没说出口的是，如此一来，借助GKE On-Prem软件和Cloud Services Platform布局，Kubernetes已经成为了企业全新的应用层，甚至可以说是新一代的应用服务器层，未来的Kubernetes云原生应用，可以在这一层快速部署，任意调度扩充和迁移，就像是新一代的通用AP层基础架构。

原文：https://www.ithome.com.tw/news/125469

1、整体分析

对于Docker来说，存在镜像、容器、存储卷和网络这些对象。因此，也就会生产相对应的这些对象，这些对象会占据磁盘空间。当这些对象不在被使用时，为了不占据额外的磁盘空间，就需要对这些对象进行清理，即进行垃圾清理。在docker 1.13版本之后，提供了对各种对象的prune命令，也提供了清理所有对象类型的docker system prune命令。但在docker 1.13之前的版本，则需要提供其他方式进行垃圾清理。

2、垃圾清理

2.1 docker v1.13之后版本的垃圾清理

2.1.1 容器

在停止容器时，系统并不会知道删除这个容器，除非在运行此容器时设置了–rm字段。停止后的容器仍然会占据磁盘的存储空间，通过docker container prune能够删除这些被停止后的容器。

$ docker container prune
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接删除已所有已停止的容器。默认情况下，此命令执行时会删除所有的已停止的容器，也可以通过设置–filter字段，来过滤所要删除的容器。例如，下面的命令仅仅删除停止超过24小时的容器。

$ docker container prune --filter "until=24h"

2.1.2 镜像

通过执行docker images prune命令可以清除所有不再使用的镜像，默认情况下此命令仅仅清除状态为dangling的镜像。状态为dangling的镜像为未被打标签和没有被任何容器引用的镜像。

$ docker image prune

WARNING! This will remove all dangling images.
Are you sure you want to continue? [y/N] y

如果要移除所有未被使用的镜像，则通过设置-a字段来实现：

$ docker image prune -a

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。可以通过设置–filter字段，来过滤所要删除的镜像。例如，下面的命令仅仅删除停止创建超过24小时的镜像。

$ docker image prune -a --filter "until=24h"

2.1.3 存储卷

存储卷可以被一个或者多个容器使用，也会占据磁盘空间。为保持数据，存储卷永远都不会自动被删除。

$ docker volume prune

WARNING! This will remove all volumes not used by at least one container.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。默认情况下，此命令执行时会删除所有的未被使用的存储卷，也可以通过设置–filter字段，来过滤所要删除的存储卷。例如，下面的命令仅仅删除label值为keep的存储卷。

$ docker volume prune --filter "label!=keep"

2.1.4 网络

docker网络并不会占据磁盘空间，但是会创建iptables规则，桥网络设备和路由表。因此，但如何不再使用这些资源时，应该对其进行清理。

$ docker network prune

WARNING! This will remove all networks not used by at least one container.
Are you sure you want to continue? [y/N] y

执行此命令时，默认会提示是否继续。如果在执行命令是设置了-f或–force字段，则会直接进行删除操作。默认情况下，此命令执行时会删除所有的未被使用的网络，也可以通过设置–filter字段，来过滤所要删除的网络。例如，下面的命令仅仅为被使用超过24小时的网络。

$ docker network prune --filter "until=24h"

2.1.5 删除所有的对象

通过docker system prune命令能够快速的删除所有的未被使用的对象，包括镜像、容器、网络和存储卷。在docker 17.06.0之前，存储卷会同时被清理。在docker 17.06.1之后，需要通过设置–volumes字段，才会同时清理存储卷。

$ docker system prune

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y

如果所使用的docker 17.06.1之后的版本，则需要在命令后添加–volumes字段来清理存储卷的内容。

$ docker system prune --volumes

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all volumes not used by at least one container
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y

2.2 docker v1.13之前版本的垃圾清理

2.2.1 容器

在停止容器时，系统并不会知道删除这个容器，除非在运行此容器时设置了–rm字段。停止后的容器仍然会占据磁盘的存储空间，通过docker rm能够删除这些被停止后的容器。通过下面的命令能够清除所有已停止的容器。

$ docker rm $(docker ps -a -q)

2.2.2 镜像

通过执行docker rmi命令可以清除所有不再使用的镜像，一般情况下仅仅清除状态为dangling的镜像。状态为dangling的镜像为未被打标签和没有被任何容器引用的镜像。

$ docker rmi $(docker images -q -f "dangling=true")

2.2.3 存储卷

存储卷可以被一个或者多个容器使用，也会占据磁盘空间。为了保持数据，存储卷永远都不会自动被删除。

$ docker volume rm $(docker volume ls -q -f dangling=true)

参考资料

1.《docker container prune》地址：https://docs.docker.com/engine/reference/commandline/container_prune/

2.《Prune unused Docker objects》地址：https://docs.docker.com/config/pruning/

3.《docker image prune》地址：https://docs.docker.com/engine/reference/commandline/image_prune/

4.《docker volume prune》地址：https://docs.docker.com/engine/reference/commandline/volume_prune/

5.《docker network prune》地址：https://docs.docker.com/engine/reference/commandline/network_prune/

作者简介：
季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。

京东首席架构师刘海锋与云原生计算基金会（CNCF）坐下来谈论云原生、京东的Kubernetes实施，以及对其它考虑开始采用开源的公司分享一些技巧和心得。以下是他们的采访。

CNCF：您如何看待您的CNCF成员资格和云原生技术，帮助京东实现“零售即服务”的愿景？

海锋：我们零售即服务（RaaS）战略的目标是开放我们的能力和资源，以增强我们的合作伙伴、供应商和其他行业的能力。这非常符合我们对开源技术的承诺。我们已经从参与的CNCF项目中获益匪浅，我们对CNCF的新承诺使我们能够与行业顶级开发商、最终用户和供应商建立更强大的合作关系，并最终使我们能够为开源社区贡献更多。我们正开发新的容器原生技术以实现我们的RaaS愿景，加入CNCF是我们迈出的重要一步。

CNCF：Kubernetes对您的公司和/或开发团队有何影响？

海锋：京东是Kubernetes最早期采用者之一。公司目前管理世界上最大的Kubernetes集群，多集群超过20,000多个裸机服务分布在多个地区的数据中心。

CNCF：Kubernetes如何帮助京东进行人工智能或大数据分析以彻底改变电子商务？

海锋：JDOS是我们定制和优化的Kubernetes版本，支持广泛的工作负载和应用程序，包括大数据和AI。JDOS提供了一个统一平台管理物理机和虚拟机，包括容器化GPU，并支持大数据和深度学习框架，如Flink、Spark、Storm和TensorFlow即服务。通过共同调度在线服务以及大数据和AI计算任务，我们显著地提高资源利用率并降低IT成本。

CNCF：京东运行的Kubernetes集群有多大？请描述一下您的团队使用Kubernetes。

海锋：JD目前管理世界上最大的Kubernetes集群，多集群超过20,000多个裸机服务分布在多个地区的数据中心

CNCF：Kubernetes和云原生如何赋能京东的开发者？哪些是他们现在能做而以前做不到的？

海锋：旧的部署工具对不同环境需要不同的流程，包括应用程序打包、容器应用程序、部署、配置和缩放。整个过程既复杂又耗时。Kubernetes的引入大大简化了流程。现在，应用程序自动打包成镜像并近乎实时地部署到容器中。缩放现在是一个简单的一键操作，可以在几秒内完成。

CNCF：京东运营世界上最大的Kubernetes集群之一，公司是如何克服障碍？

海锋：我们一直监控系统的性能。过去，为解决性能的问题，我们收集并分析了几个关键绩效指标，并生成了详细的瓶颈分析报告。然后，我们通过删除不必要的函数和优化默认的调度程序来定制Kubernetes。我们还增强了多个控制器以避免级联故障。此外，我们还开发了用于检查、监控、报警和故障处理的操作工具包，帮助操作员排除故障并快速解决可能出现的任何问题。

CNCF：京东刚刚庆祝大名鼎鼎的6月18日全民年中购物节（“618”），在18天期间交易量超过247亿美元。这是很大量的订单。您能谈谈您的系统如何处理这么多的订单吗？

海锋：JDOS使用基于预测的算法，主动分配资源以满足预测需求，提高资源利用率。它还提供毫秒级弹性扩展，处理极端工作负载。我们每年举办的618全民年中购物节，今年的交易量达到了247亿美元。我们的平台有超过3亿客户，在此期间我们看到显着的流量高峰。我们调度了大约460,000个容器（Pod）和3,000,000个CPU核心，以支持大量订单。

CNCF：告诉我们您的Vitess使用情况。有什么影响？

海锋：我们的弹性数据库是世界上规模最大、最复杂的Vitess部署之一。我们已经成功地扩展了Vitess，在JD的Kubernetes平台上管理大量复杂的交易数据。显著的功能包括支持RocksDB和TokuDB作为新的存储引擎、自动重新分片、自动负载平衡和迁移。我们的系统目前管理2,600个MySQL集群、9,000个MySQL实例、350,000个表、1,600亿条记录和65T数据，支持京东的各种业务应用程序和服务。Vitess的使用使我们能够更灵活、更有效地管理资源，从而显著降低运营和维护成本。我们正积极与CNCF社区合作，向Vitess添加子查询支持和全域交易等新功能。

CNCF：您公司对Kubernetes和其它云原生技术（GitLab、Jenkins、Logstash、HarbourElasticsearch和Prometheus）的下一步是什么？

海锋：我们的容器化平台通过在Kubernetes上部署DevOps堆栈来分离应用程序和基础架构层，包括Vitess、Prometheus、GitLab、Jenkins、Logstash、Harbour和Elasticsearch等。我们贡献了代码到其中一些项目。我们希望将来能够做出更多贡献。我们认为可以真正增加价值的一个例子是Vitess，CNCF的可扩展MySQL集群管理项目。我们不仅是Vitess的最大最终用户，也是一个非常活跃和重要的贡献者。我们期待与CNCF社区的其他人一起为Vitess添加新功能，包括子查询支持、全域交易等。另外，我们正在扩展Prometheus以创建实时和高性能的监控系统。我们希望改进Kubernetes以支持多种不同的工作负载，并希望为Kubernetes贡献代码。

我们也计划发布我们的内部自研项目。在github.com/tiglabs上能找到很多。我们还计划提出新的CNCF项目。其中一个项目是ContainerFS。它是一个与Kubernetes无缝集成的大规模容器原生集群文件系统。

CNCF：您目前也正在评估哪些技术或实践（DevOps，CI / CD）？

海锋：我们正在积极开发以云原生或容器原生软件和技术为中心的开源项目，从计算、存储和中间件到应用程序。其中一个重点是用于各种工作负载的容器平台，包括在线服务、数据分析、边缘计算和物联网。另一个重点是容器平台的可扩展和高性能数据存储。

CNCF：对于刚刚开始使用云原生的其他中国公司，最重要的事情是什么？

海锋：借助Docker、Kubernetes和微服务，您可以从云原生获得很多价值而无需承受高额成本。云原生解决方案不仅可以在云中运行。它非常灵活，可以部署在内部环境、私有云、公共云和混合环境中。重要的是要密切关注新技术和行业趋势，利用开源技术并积极参与开源社区。

CNCF：对于希望部署云原生基础架构的其他公司，您有什么建议？

海锋：从生态系统的角度考虑如何满足您的业务需求，包括容器化基础设施、数据存储、微服务平台、消息传递和监控系统等。在容器编排和管理方面，Kubernetes是事实上的标准，是肯定的能押注的。您还应该利用新兴的无服务器架构来简化应用程序开发、打包、部署和管理的过程。

CNCF：为什么云原生对京东的商业是如此势在必行？

海锋：除了我们的商家外，我们拥有超过3亿客户，我们的基础设施必须具有可扩展性和极高的效率。五年前，我们的产品图像系统中有大约20亿个图像。今天，有超过一万亿，这个数字每天增加1亿。此外，作为中国最大的在线或离线零售商，同时也是中国最大的电子商务物流基础设施的运营商，完全由内部自力开发，我们的业务复杂且日新月异。因此，我们的基础架构必须非常灵活，并支持广泛的工作负载和应用场景，如在线服务、数据分析、AI、供应链、财务、物联网或边缘计算等。云原生技术非常适合处理我们不断变化的需求。

CNCF：这是京东加入的第一个开源基金会吗？

海锋：对。我们坚定地相信开源，并且与我们自己的战略密切配合。通过CNCF，我们的目标是与开源社区建立更多更强大的交流互动，并充分发现为开源社区做出贡献的潜在互利。作为全球以收入计算第三大互联网公司，京东已经开发了许多领先的技术创新，我们认识到我们有责任在开源社区中发挥领导作用。

CNCF：您打算如何与CNCF携手合作？

海锋：我们可以合作的领域是无限的。当我们推进一些新项目，加入CNCF并与其他成员合作将非常有帮助。此外，CNCF为我们提供了平台，提高我们某些项目的推广认识，招募领先的开发者，进行协作并为我们的工作做出贡献。

CNCF：您对KubeCon + CloudNativeCon中国论坛的内容感到兴奋吗？

海锋：我们期待与行业顶级开发商、最终用户和供应商会面，并继续了解最新的技术发展。我们还计划展示自己的工作，并确定与公司、最终用户和独立开发者的潜在合作机会。

想更多地了解中国的技术领导者如何利用云原生技术？11月14日至15日，参与我们在上海举办的首届KubeCon + CloudNativeCon中国论坛。希望能在那里见到您！

从2017年9月开始，公有云服务商DigitalOcean开始每季发布开发者调查报告。每一季的报告，都会根据当时IT趋势而有所差异，像今年3月所发布的报告，就针对欧盟个资保护法GDPR，以及FCC决定废止网络中立性的政策，了解使用者的想法。这次该公司发布的使用者调查报告，访问了全球近5,000名开发者，了解各企业对容器、（无服务器）Serverless以及其他软件开发工具的使用趋势。

「容器技术的开发动能仍在增强」，DigitalOcean表示，随着容器技术、容器调度管理工具的快速进步，已经有49％的使用者开始利用容器技术，在软件开发上，容器技术已经可说是开发者必备的工具之一。相比之下，Serverless应用仍处于早期采用阶段，半数开发者对Serverless技术相当陌生。至于已经尝试使用该技术的开发者，「监控及除错是他们碰上最大的挑战。」

当Docker公司将容器技术热潮掀起时，Docker容器的快速开启、快速部署，以及高移植性等特性马上就受到开发者的热烈欢迎。调查报告显示，有39％的开发者认为，容器技术的高度扩充性是此技术带来最大的效益。而第二个受到使用者青睐的特质，就是让软件开发变得更简单（24％）。值得注意的是，容器技术的便捷性，能解决企业被特定厂商死锁的特质，也受到10％的开发者认同。

而利用容器技术镜像建立标准交付格式，也是开发圈加快应用交付的常见用法。在CI/CD流程与容器应用整合中，有42％的受访者表示，他们会结合持续整合、持续交付工具，加速容器应用生命周期的自动化。

在提到容器技术时，也一定会谈到容器调度工具的导入。当基础架构规格超过一定程度时，必须仰赖这些工具管理庞大的容器集群。果不其然，Kubernetes以42％的使用率拔得此份调查头筹。而Docker Swarm仍然有一定影响力，有35％的开发者仍继续使用该工具。而原本与Kubernetes、Docker Swarm三分天下的Mesos，仅剩3％的开发者使用。

不过，DigitalOcean表示，已经开始用容器的开发者，仍有52％还未导入容器调度平台。在调查容器调度工具议题中，DigitalOcean也发现几个有趣的结论。在1至5人的微型企业，Docker Swarm的使用率（41％）比Kubernetes（31％）还更高。而使用容器调度工具的开发者，超过半数（51％）每周都因此省下至少5小时的维运时间。

除了容器技术，Serverless应用也是这次DigitalOcean的调查重点。除云端容器服务，当今公有云厂商也开始建立Serverless应用平台，插入这块新市场。调查开始使用Serverless应用的用户群体中，结果显示，58％的用户导入了AWS Lambda作为Serverless应用执行平台，殿后的是Google Cloud Functions（23％），而微软Azure Functions则以10％拿下第三名。

比照容器技术调查，DigitalOcean也访问使用者，了解Serverless技术带来的优点。而该技术最受青睐的特色，就是省去使用者自行建立服务器的成本（33％），其次则是让开发者能花更多时间改善应用（28％）。再者是让应用能更快速部署（23％）。

而历经三五年酝酿的容器技术，在厂商、社群积极推广下已逐渐成熟。相比之下，Serverless应用还属于早期采用阶段。尚未熟悉该技术的开发者，有81％受访者表示，会在今年起深入了解研究。而已经导入Serverless应用的开发者，最多人碰上的挑战是该应用不易监控、除错（27％）。而当今Serverless应用也相当依赖公有云厂商服务，因此，其中有25％开发者担心被厂商绑定，20％更表示导入Serverless应用，得依赖第三方厂商提供的解决方案。

图片来源：DigitalOcean

有39％的开发者认为，容器技术的高度扩充性是此技术带来最大的效益。而第二个受到使用者青睐的特质，就是让软件开发变得更简单（24％）。

图片来源：DigitalOcean

Kubernetes以42％的使用率拔得此份调查头筹。而Docker Swarm仍然有一定影响力，有35％的开发者仍继续使用该工具。而原本与Kubernetes、Docker Swarm三分天下的Mesos，仅剩3％的开发者使用。

图片来源：DigitalOcean

开始应用Serverless技术的企业，58％的使用者导入了AWS Lambda作为Serverless应用执行平台，殿后的是Google Cloud Functions（23％），而微软Azure Functions则以10％拿下第三名。

图片来源：DigitalOcean

开发者使用容器搭配的程序语言，按照使用排名依序是JavaScript（57％）、Python（46％）、PHP（36％）、Go（28％）、Java（27％）等。

原文：https://www.ithome.com.tw/news/124290

今天，我们兴奋地公布Kubernetes 1.11版本——亦是2018年这一项目的第二个发布版本！

今天发布的版本旨在不断推进Kubernetes的成熟度、可扩展性与灵活性，同时亦标志着其研发团队在过去一年中的努力工作取得了重大进展。这一最新版本的主要亮点集中在网络层面，以beta测试形式开放来自SIG-API Machinery与SIG-Node的两项主要功能，同时进一步增强在此前两个版本中已经得到高度重视的存储功能。在这一最新版本中，用户将能够更轻松地将任意基础设施——无论云平台还是内部环境——接入Kubernetes当中。

本版本当中最值得关注的，是增加了两项备受期待的功能，分别为：基于IPVS的集群内负载均衡，以及将CoreDNS作为集群DNS的附加选项——这意味着生产应用的可扩展性与灵活性都将得到提升。

下面，我们将就最新版本的核心特性展开讨论：

基于IPVS的集群内服务负载均衡正式上线

在本次版本中，基于IPVS的集群内服务负载均衡功能已经趋于稳定。IPVS（即IP虚拟服务器）能够提供高性能内核负载均衡功能，且其编程接口较iptables更为简单。这一变化使得网络吞吐量更上一层楼、提供更低的编程延迟，同时亦使由Kubernetes Service模式组成的集群范围内分布式负载均衡器获得更高的可扩展性水平。目前IPVS仍不属于默认设置，但大家已经可以利用其处理生产流量。

CoreDNS正式上线

CoreDNS现在被正式作为集群DNS附加选项，且在用户使用kubeadm时默认生效。CoreDNS是一套灵活且可扩展的权威DNS服务器，可直接与Kubernetes API相集成。相较于原有DNS服务器，CoreDNS的移动部件更少——仅包含单一可执行文件与单一进程，且允许用户通过创建自定义DNS条目以支持更为灵活的用例。其同样使用Go语言编写而成，因此天然具备更理想的安全性水平。感兴趣的朋友可以点击此处参阅关于CoreDNS的更多细节信息。

动态Kubelet配置步入Beta测试阶段

通过这项改进，用户可以将新的Kubelet配置部署在运行中的集群之内。在此之前，Kubelet需要通过命令行标记进行配置，这导致我们很难对运行中的集群进行Kubelet配置更新。在此次beta功能的帮助下，用户将能够通过API服务器随时配置运行中集群内的Kubelet。

定制化资源定义现在可定义多个版本

定制化资源定义不再局限于对单一版本的定制化资源作出定义。如今，利用此项beta测试功能，用户可以为资源定义多个版本。未来，其还将进一步扩展以支持版本间自动转换功能。目前，该功能允许定制化资源作者“以安全变更的方式实现版本升级，例如由v1beta1切换至v1”，并为发生变化的资源创建迁移路径。

定制化资源定义如今还能够支持“状态”与“规模”两类子资源，这些子资源可与各类监控与高可用性框架相集成。这两项变化显著提升了在生产环境中利用定制化资源定义运行云原生应用程序的能力。

CSI增强

容器存储接口（简称CSI）在之前的几个版本当中一直得到高度关注。在1.10版本以beta形式发布之后，1.11版本进一步增强了CSI功能。1.11版本为CSI带来了对原始数据块分卷的alph支持能力，将CSI与新的kubelet插件注册机制相集成，同时降低了向CSI插件传递秘密凭证的难度。

新的存储功能

对持久分卷进行在线大小调整已经以alpha测试功能的形式引入新版本。这意味着用户能够增加持久分卷的大小，而完全无需终止pod并卸载对应分卷。用户可以更新VPC以提交新的分卷大小请求，kubelet则负责完成文件系统的大小调整。

动态最大分卷数量以alpha测试版的形式加入新版本。这项新功能使得入树分卷插件能够指定可接入节点的最大分卷数量，且允许根据节点类型的区别设定不同最大分卷量。在此之前，这些限制需要通过硬编码形式或配置环境变量来实现。

StorageObjectInUseProtection功能目前已经迎来稳定版本，并可防止绑定至持久分卷声明的持久分卷以及由pod使用的持久分卷声明遭到删除。此项安全措施将有助于防止用户不小心删除绑定至运行中pod的PV或PVC。

社区中的各个特别兴趣小组（简称SIG）都将继续立足各自专业领域实现呼声最高的增强、修复与功能。关于SIG的完整内容列表，请点击此处参阅发行版说明。

正式上线

Kubernetes 1.11目前已经可通过GitHub进行下载。要开始使用Kubernetes，请点击此处参阅相关交互式教程。

您也可以利用Kubeadm安装1.11版本。1.11.0版本将以Deb与RPM软件包的形式提供，并于6月28日通过Kubeadm集群安装器进行安装。

原文链接：Kubernetes 1.11: In-Cluster Load Balancing and CoreDNS Plugin Graduate to General Availability

来源：http://www.dockone.io/article/6050

1、Prometheus介绍和架构

1.1 Prometheus介绍

Prometheus是一个开源的系统监视和警报工具包，自2012成立以来，许多公司和组织采用了Prometheus。它现在是一个独立的开源项目，并独立于任何公司维护。在2016年，Prometheus加入云计算基金会作为Kubernetes之后的第二托管项目。
Prometheus的关键特性如下：

• 由度量名和键值对标识的时间序列数据的多维数据模型
• 灵活的查询语言
• 不依赖于分布式存储；单服务器节点是自治的
• 通过HTTP上的拉模型实现时间序列收集
• 通过中间网关支持推送时间序列
• 通过服务发现或静态配置发现目标
• 图形和仪表板支持的多种模式

Prometheus的组件：

Prometheus生态由多个组件组成，并且这些组件大部分是可选的：

• Prometheus服务器，用于获取和存储时间序列数据；
• 仪表应用数据的客户端类库(Client Library)
• 支持临时性工作的推网关(Push Gateway)
• 特殊目的的输出者(Exporter)，提供被监控组件信息的 HTTP 接口，例如HAProxy、StatsD、MySQL、Nginx和Graphite等服务都有现成的输出者接口
• 处理告警的告警管理器（Alert Manager）
• 其它支持工具

Prometheus的整体架构

Prometheus从jobs获取度量数据，也直接或通过推送网关获取临时jobs的度量数据。它在本地存储所有被获取的样本，并在这些数据运行规则，对现有数据进行聚合和记录新的时间序列，或生成警报。通过Grafana或其他API消费者，可以可视化的查看收集到的数据。下图显示了Pometheus的整体架构和生态组件：

Prometheus的整体工作流程：

1）Prometheus 服务器定期从配置好的 jobs 或者 exporters 中获取度量数据；或者接收来自推送网关发送过来的 度量数据。

2）Prometheus 服务器在本地存储收集到的度量数据，并对这些数据进行聚合；

3）运行已定义好的 alert.rules，记录新的时间序列或者向告警管理器推送警报。

4）告警管理器根据配置文件，对接收到的警报进行处理，并通过email等途径发出告警。

5）Grafana等图形工具获取到监控数据，并以图形化的方式进行展示。

1.2 Prometheus关键概念

1.2.1 数据模型

Prometheus从根本上将所有数据存储为时间序列：属于相同度量标准和同一组标注尺寸的时间戳值流。除了存储的时间序列之外，普罗米修斯可能会生成临时派生时间序列作为查询的结果。

• 度量名称和标签：每个时间序列都是由度量标准名称和一组键值对（也称为标签）组成唯一标识。度量名称指定被测量的系统的特征（例如：http_requests_total-接收到的HTTP请求的总数）。它可以包含ASCII字母和数字，以及下划线和冒号。它必须匹配正则表达式[a-zA-Z_:][a-zA-Z0-9_:]*。标签启用Prometheus的维度数据模型：对于相同度量标准名称，任何给定的标签组合都标识该度量标准的特定维度实例。查询语言允许基于这些维度进行筛选和聚合。更改任何标签值（包括添加或删除标签）都会创建新的时间序列。标签名称可能包含ASCII字母，数字以及下划线。他们必须匹配正则表达式[a-zA-Z_][a-zA-Z0-9_]*。以__开始的标签名称保留给供内部使用。

• 样本：实际的时间序列，每个序列包括：一个 float64 的值和一个毫秒级的时间戳。

• 格式：给定度量标准名称和一组标签，时间序列通常使用以下格式来标识：

  <metric name>{<label name>=<label value>, ...}
  

  例如，时间序列的度量名称为api_http_requests_total，标签method=”POST”和handler=”/messages”，则标记为：

  api_http_requests_total{method="POST", handler="/messages"}

1.2.2 度量类型

Prometheus 客户端库主要提供Counter、Gauge、Histogram和Summery四种主要的 metric 类型：

• Counter(计算器)：Counter是一种累加的度量，它的值只能增加或在重新启动时重置为零。例如，您可以使用计数器来表示提供的请求数，已完成的任务或错误的数量。不要使用计数器来表达可减少的值。例如，不要使用Counter来计算当前正在运行的进程的数量，而是使用Gauge。
• Gauge(测量)：Gauge表示单个数值，表达可以任意地上升和下降的度量。Gauge通常用于测量值，例如温度或当前的内存使用情况，但也可以表达上升和下降的“计数”，如正在运行的goroutines的数量。

• Histogram(直方图)：Histogram样本观测（例如：请求持续时间或响应大小），并将它们计入配置的桶中。它也提供所有观测值的总和。具有<basename>基本度量标准名称的histogram的在获取数据期间会显示多个时间序列：
  • 观察桶的累计计数器，暴露为 <basename>_bucket{le=”<upper inclusive bound>”}
  • 所有观察值的总和，暴露为<basename>_sum
  • 已观察到的事件的计数，暴露为<basename>_count（等同于<basename>_bucket{le=”+Inf”}）

  Summery：类似于Histogram，Summery样本观察（通常是请求持续时间和响应大小）。虽然它也提供观测总数和所有观测值的总和，但它计算滑动时间窗内的可配置分位数。在获取数据期间，具有<basename>基本度量标准名称的Summery会显示多个时间序列：

  • 流动φ分位数（0≤φ≤1）的观察事件，暴露为<basename>{quantile=”<φ>”}
  • 所有观察值的总和，暴露为<basename>_sum
  • 已经观察到的事件的计数，暴露为<basename>_count

1.2.3 工作和实例

按照Prometheus的说法，可以获取数据的端点被称为实例（instance），通常对应于一个单一的进程。具有相同目的的实例集合（例如为了可伸缩性或可靠性而复制的进程）称为作业（job）。

例如，具有四个复制实例的API服务器作业：

• 工作： api-server
  • 实例1： 1.2.3.4:5670
  • 实例2： 1.2.3.4:5671
  • 实例3： 5.6.7.8:5670
  • 实例4： 5.6.7.8:5671

自动生成标签和时间序列

当Prometheus获取目标时，它会自动附加一些标签到所获取的时间序列中，以识别获取目标：

• job：目标所属的配置作业名称。
• instance：<host>:<port>被抓取的目标网址部分。

如果这些标签中的任何一个已经存在于抓取的数据中，则行为取决于honor_labels配置选项。

对于每个实例抓取，Prometheus会在以下时间序列中存储一个样本：

• up{job=”<job-name>”, instance=”<instance-id>”}：1 如果实例健康，即可达；或者0抓取失败。
• scrape_duration_seconds{job=”<job-name>”, instance=”<instance-id>”}：抓取的持续时间。
• scrape_samples_post_metric_relabeling{job=”<job-name>”, instance=”<instance-id>”}：应用度量标准重新标记后剩余的样本数。
• scrape_samples_scraped{job=”<job-name>”, instance=”<instance-id>”}：目标暴露的样本数量。

up时间序列是实例可用性的监控。

1.3 使用Helm在Kubernetes中部署Prometheus

1.3.1 环境要求

• 已有Kubernetes 1.6+环境；
• 已部署helm客户端和tiller服务端（请参考：https://docs.helm.sh/using_helm/#installing-helm）：
  • 在Kubernetes中创建了具备足够权限访问权限的service account；
  • 并通过此service account在Kubernetes部署了tiller服务端（请参考：https://docs.helm.sh/using_helm/#role-based-access-control）。
• 在Kubernetes中提供2个容量大于10g的持久化存储卷。

1.3.2 Helm chart配置

下表列示了Prometheus chart的配置参数和默认值：

1、持久化存储卷和声明介绍

PersistentVolume（PV）用于为用户和管理员提供如何提供和消费存储的API，PV由管理员在集群中提供的存储。它就像Node一样是集群中的一种资源。PersistentVolume 也是和存储卷一样的一种插件，但其有着自己独立的生命周期。PersistentVolumeClaim (PVC)是用户对存储的请求，类似于Pod消费Node资源，PVC消费PV资源。Pod能够请求特定的资源(CPU和内存)，声明请求特定的存储大小和访问模式。PV是一个系统的资源，因此没有所属的命名空间。

2、持久化存储卷和声明的生命周期

在Kubernetes集群中，PV 作为存储资源存在。PVC 是对PV资源的请求和使用，也是对PV存储资源的”提取证”，而Pod通过PVC来使用PV。PV 和 PVC 之间的交互过程有着自己的生命周期，这个生命周期分为5个阶段：

• 供应(Provisioning)：即PV的创建，可以直接创建PV（静态方式），也可以使用StorageClass动态创建
• 绑定（Binding）：将PV分配给PVC
• 使用（Using）：Pod通过PVC使用该Volume
• 释放（Releasing）：Pod释放Volume并删除PVC
• 回收（Reclaiming）：回收PV，可以保留PV以便下次使用，也可以直接从云存储中删除

根据上述的5个阶段，存储卷的存在下面的4种状态：

• Available：可用状态，处于此状态表明PV以及准备就绪了，可以被PVC使用了。
• Bound：绑定状态，表明PV已被分配给了PVC。
• Released：释放状态，表明PVC解绑PV，但还未执行回收策略。
• Failed：错误状态，表明PV发生错误。

2.1 供应（Provisioning）

供应是为集群提供可用的存储卷，在Kubernetes中有两种持久化存储卷的提供方式：静态或者动态。

2.1.1 静态(Static)

PV是由Kubernetes的集群管理员创建的，PV代表真实的存储，PV提供的这些存储对于集群中所有的用户都是可用的。它们存在于Kubernetes API中，并可被Pod作为真实存储使用。在静态供应的情况下，由集群管理员预先创建PV，开发者创建PVC和Pod，Pod通过PVC使用PV提供的存储。静态供应方式的过程如下图所示：

2.1.2 动态（Dynamic）

对于动态的提供方式，当管理员创建的静态PV都不能够匹配用户的PVC时，集群会尝试自动为PVC提供一个存储卷，这种提供方式基于StorageClass。在动态提供方向，PVC需要请求一个存储类，但此存储类必须有管理员预先创建和配置。集群管理员需要在API Server中启用DefaultStorageClass的接入控制器。动态供应过程如下图所示：

2.2 绑定

在Kubernetes中，会动态的将PVC与可用的PV的进行绑定。在kubernetes的Master中有一个控制回路，它将监控新的PVC，并为其查找匹配的PV（如果有），并把PVC和PV绑定在一起。如果一个PV曾经动态供给到了一个新的PVC，那么这个回路会一直绑定这个PV和PVC。另外，用户总是能得到它们所要求的存储，但是volume可能超过它们的请求。一旦绑定了，PVC绑定就是专属的，无论它们的绑定模式是什么。

如果没有匹配的PV，那么PVC会无限期的处于未绑定状态，一旦存在匹配的PV，PVC绑定此PV。比如，就算集群中存在很多的50G的PV，需要100G容量的PVC也不会匹配满足需求的PV。直到集群中有100G的PV时，PVC才会被绑定。PVC基于下面的条件绑定PV，如果下面的条件同时存在，则选择符合所有要求的PV进行绑定:

1）如果PVC指定了存储类，则只会绑定指定了同样存储类的PV；

2）如果PVC设置了选择器，则选择器去匹配符合的PV;

3）如果没有指定存储类和设置选取器，PVC会根据存储空间容量大小和访问模式匹配符合的PV。

2.3 使用

Pod把PVC作为卷来使用，Kubernetes集群会通过PVC查找绑定的PV，并将其挂接至Pod。对于支持多种访问方式的卷，用户在使用 PVC 作为卷时，可以指定需要的访问方式。一旦用户拥有了一个已经绑定的PVC，被绑定的PV就归该用户所有。用户能够通过在Pod的存储卷中包含的PVC，从而访问所占有的PV。

2.４释放

当用户完成对卷的使用时，就可以利用API删除PVC对象了，而且还可以重新申请。删除PVC后，对应的持久化存储卷被视为“被释放”，但这时还不能给其他的PVC使用。之前的PVC数据还保存在卷中，要根据策略来进行后续处理。

2.5 回收

PV的回收策略向集群阐述了在PVC释放卷时，应如何进行后续工作。目前可以采用三种策略：保留，回收或者删除。保留策略允许重新申请这一资源。在PVC能够支持的情况下，删除策略会同时删除卷以及AWS EBS/GCE PD或者Cinder卷中的存储内容。如果插件能够支持，回收策略会执行基础的擦除操作（rm -rf /thevolume/*），这一卷就能被重新申请了。

2.5.1 保留

保留回收策略允许手工回收资源。当PVC被删除，PV将仍然存储，存储卷被认为处于已释放的状态。但是，它对于其他的PVC是不可用的，因为以前的数据仍然保留在数据中。管理员能够通过下面的步骤手工回收存储卷：

1）删除PV：在PV被删除后，在外部设施中相关的存储资产仍然还在；

2）手工删除遗留在外部存储中的数据；

3）手工删除存储资产，如果需要重用这些存储资产，则需要创建新的PV。

2.5.2 循环

警告：此策略将会被遗弃。建议后续使用动态供应的模式。

循环回收会在存储卷上执行基本擦除命令：rm -rf /thevolume/*，使数据对于新的ＰＶＣ可用。

2.5.3 删除

对于支持删除回收策略的存储卷插件，删除即会从Kubernetes中移除PV，也会从相关的外部设施中删除存储资产，例如AWS EBS, GCE PD, Azure Disk或者Cinder存储卷。

3、持久化存储卷

在Kubernetes中，PV通过各种插件进行实现，当前支持下面这些类型的插件：

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• FC (Fibre Channel)
• FlexVolume
• Flocker
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• HostPath (Single node testing only – local storage is not supported in any way and WILL NOT WORK in a multi-node cluster)
• VMware Photon
• Portworx Volumes
• ScaleIO Volumes
• StorageOS

持久化存储卷的可以通过YAML配置文件进行，并指定使用哪个插件类型，下面是一个持久化存储卷的YAML配置文件。在此配置文件中要求提供5Gi的存储空间，存储模式为Filesystem ，访问模式是ReadWriteOnce，通过Recycle回收策略进行持久化存储卷的回收，指定存储类为slow，使用nfs的插件类型。需要注意的是，nfs服务需要提供存在。

apiVersion:v1
kind:PersistentVolume
metadata:
  name:pv0003
spec:
  capacity: #容量
     storage:5Gi
  volumeMode:Filesystem #存储卷模式
  accessModes: #访问模式
  - ReadWriteOnce
  persistentVolumeReclaimPolicy:Recycle #持久化卷回收策略
  storageClassName:slow #存储类
  mountOptions: #挂接选项
   - hard
   - nfsvers=4.1
  nfs:
     path:/tmp
     server:172.17.0.2 

3.1 容量（Capacity）

一般来说，PV会指定存储容量。这里通过使用PV的capcity属性进行设置。目前，capcity属性仅有storage（存储大小）这唯一一个资源需要被设置。

3.2 存储卷模式（Volume Mode）

在kubernetes v1.9之前的版本，存储卷模式的默认值为filesystem，不需要指定。在v1.9版本，用户可以指定volumeMode的值，除了支持文件系统外（file system）也支持块设备（raw block devices）。volumeMode是一个可选的参数，如果不进行设定，则默认为Filesystem。

3.3 访问模式（Access Modes）

只要资源提供者支持，持久卷能够通过任何方式加载到主机上。每种存储都会有不同的能力，每个PV的访问模式也会被设置成为该卷所支持的特定模式。例如NFS能够支持多个读写客户端，但某个NFS PV可能会在服务器上以只读方式使用。每个PV都有自己的一系列的访问模式，这些访问模式取决于PV的能力。

访问模式的可选范围如下：

•   ReadWriteOnce：该卷能够以读写模式被加载到一个节点上。
•   ReadOnlyMany：该卷能够以只读模式加载到多个节点上。
•   ReadWriteMany：该卷能够以读写模式被多个节点同时加载。

在 CLI 下，访问模式缩写为：

•   RWO：ReadWriteOnce
•   ROX：ReadOnlyMany
•   RWX：ReadWriteMany

一个卷不论支持多少种访问模式，同时只能以一种访问模式加载。例如一个 GCEPersistentDisk既能支持ReadWriteOnce，也能支持ReadOnlyMany。

3.4 类（Class）

在PV中可以指定存储类，通过设置storageClassName字段进行设置。如果设置了存储类，则此PV只能被绑定到也指定了此存储类的PVC。在以前的版本中，使用注释volume.beta.kubernetes.io/storage-class字段来指定存储类，而不是storageClassName字段来指定存储类。 此注释仍然可用，但是，在将来的版本中将会被废弃。

3.5 回收策略

当前的回收策略可选值包括：

• Retain-持久化卷被释放后，需要手工进行回收操作。
• Recycle-基础擦除（“rm-rf /thevolume/*”）
• Delete-相关的存储资产，例如AWSEBS或GCE PD卷一并删除。

目前，只有NFS和HostPath支持Recycle策略，AWSEBS、GCE PD支持Delete策略。

3.6 挂接选项（Mount Options）

当持久化卷被挂接至Pod上时，管理员能够指定额外的挂接选项。但不是所有的持久化卷类型都支持挂接选项，下面的存储卷类型支持挂接选项：

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• VMware Photon

挂接选项不会进行验证，因此如果如果设置不正确，则会失败。在以前的版本中，使用volume.beta.kubernetes.io/mount-options注释指定挂接选项，而不是使用mountOptions字段。此注释仍然可用，但是在将来的版本中将会被废弃。

4、持久化卷声明

下面是一个名称为myclaim的PVC YAML配置文件，它的访问模式为ReadWriteOnce，存储卷模式是Filesystem，需要的存储空间大小为8Gi，指定的存储类为slow，并设置了标签选择器和匹配表达式。

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes: #访问模式
    - ReadWriteOnce
  volumeMode: Filesystem #存储卷模式
  resources: #资源
    requests:
      storage: 8Gi
  storageClassName: slow #存储类
  selector: #选择器
    matchLabels:
      release: "stable"
    matchExpressions: #匹配表达式
      - {key: environment, operator: In, values: [dev]}

4.1 选择器

在PVC中，可以通过标签选择器来进一步的过滤PV。仅仅与选择器匹配的PV才会被绑定到PVC中。选择器的组成如下：

• matchLabels： 只有存在与此处的标签一样的PV才会被PVC选中；
• matchExpressions ：匹配表达式由键、值和操作符组成，操作符包括In, NotIn, Exists和DoesNotExist，只有符合表达式的PV才能被选择。

如果同时设置了matchLabels和matchExpressions，则会进行求与，即只有同时满足上述匹配要求的PV才会被选择。

4.2 存储类

如果PVC使用storageClassName字段指定一个存储类，那么只有指定了同样的存储类的PV才能被绑定到PVC上。对于PVC来说，存储类并不是必须的。依赖于安装方法，可以在安装过程中使用add-on管理器将默认的StorageClass部署至Kubernetes集群中。当PVC指定了选择器，并且指定了StorageClass，则在匹配PV时，取两者之间的与：即仅仅同时满足存储类和带有要求标签值的PV才能被匹配上。

4.3 PVC作为存储卷

Pod通过使用PVC来访问存储，而PVC必须和使用它的Pod在同一个命名空间中。Pod会同一个命名空间中选择一个合适的PVC，并使用PVC为其获取存储卷，并将PV挂接到主机和Pod上。

kind:Pod
apiVersion:v1
metadata:
  name:mypod
spec:
  containers:
  - name:myfrontend
    image:dockerfile/nginx
     volumeMounts: #挂接存储卷
     - mountPath:"/var/www/html" #挂接的路径
       name:mypd #所要挂接的存储卷的名称
 volumes: #定义存储卷
 - name:mypd
   persistentVolumeClaim: #所使用的持久化存储卷声明
     claimName:myclaim

参考资料

1.《Configure a Pod to Use a PersistentVolume for Storage》地址：https://kubernetes.io/docs/tasks/configure-pod-container/configure-persistent-volume-storage/

2.《Persistent Volumes》地址：https://kubernetes.io/docs/concepts/storage/persistent-volumes/

3.《Persistent Storage》地址：https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/persistent-storage.md

4.《PersistentVolume v1 core》地址：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#persistentvolume-v1-core

作者简介：
季向远，北京神舟航天软件技术有限公司产品经理。本文版权归原作者所有。

1、基于kubernetes devops的整体方案

本文以Kubernetes为基础，为基于java语言研发团队提供一套完整的devops解决方案。在此方案中，开发人员基于eclipse集成开发环境进行代码；开发人员所开发的代码交由由gitlab进行托管、版本管理和分支管理；代码的依赖更新和构建工作由Maven进行处理；为了提升工作效率和代码质量，在devops中引入SonarQube进行代码检查；对于打包构建后代码，交由docker进行镜像构建，并在私有镜像仓库中对镜像进行管理；最后，devops会将自动从私有镜像仓库从拉取镜像，并在Rancher中进行部署。

基于此devops解决方案的整体工作过程如下所示：

1）开发人员基于eclipse集成开发环境镜像代码开发的，将代码到gitlab中进行托管；

2）jenkins从gitlab拉取代码；

3）jenkins调用Maven对代码进行打包构建；

4）jenkins调用docker构建镜像；

5）jenkins将构建好的镜像上传至基于Nexus的私有镜像仓库；

6）jenkins拉取镜像，并部署镜像至Rancher中。

2、组件安装部署

此部分描述需要为devops部署的组件，根据整体方案，devops需要使用gitlab、jenkins、nexus、maven、docker和kubernetes这些组件和系统。其中，gitlab、jenkins、nexus都在kubernetes中安装部署，在jenkins中包含了maven；docker直接在物理机提供，对于docker的部署不在此部分进行阐述。

2.1 代码托管工具-Gitlab

在本文的方案中，代码的托管基于Gitlab。下面是在Kubernetes中部署gitlab的YAML配置文件，在此文件中定义了gitlab部署和服务。gitlab部署使用的镜像为gitlab/gitlab-ce:latest，并暴露了443、80和22这三个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对gitlab进行访问。

#------------------------定义代理服务-------------------------
apiVersion: v1
kind: Service
metadata:
  name: gitlab
spec:
  type: NodePort
  ports:
  # Port上的映射端口
  - port: 443
    targetPort: 443
    name: gitlab443
  - port: 80
    targetPort: 80
    name: gitlab80
  - port: 22
    targetPort: 22
    name: gitlab22
  selector:
    app: gitlab
---

# ------------------------定义Gitlab的部署 -----------------------

apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: gitlab
spec:
  selector:
    matchLabels:
      app: gitlab
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: gitlab
    spec:
      containers:
      # 应用的镜像
      - image: gitlab/gitlab-ce 
        name: gitlab
        imagePullPolicy: IfNotPresent
        # 应用的内部端口
        ports:
        - containerPort: 443
          name: gitlab443
        - containerPort: 80
          name: gitlab80
        - containerPort: 22
          name: gitlab22
        volumeMounts:
        # gitlab持久化
        - name: gitlab-persistent-config
          mountPath: /etc/gitlab
        - name: gitlab-persistent-logs
          mountPath: /var/log/gitlab
        - name: gitlab-persistent-data
          mountPath: /var/opt/gitlab
      imagePullSecrets:
      - name: devops-repo
      volumes:
      # 使用nfs互联网存储
      - name: gitlab-persistent-config
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/gitlab/config
      - name: gitlab-persistent-logs
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/gitlab/logs
      - name: gitlab-persistent-data
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/gitlab/data

通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署gitlab：

$ kubectl create -f {path}/gitlab.yaml

2.2 镜像仓库-Nexus

在本文的devops方案中，采用Nexus作为docker私有镜像仓库和maven的远程仓库。下面是在Kubernetes中部署Nexus的YAML配置文件，在此文件中定义了Nexus部署和服务。Nexus部署使用的镜像为sonatype/nexus3:latest，并暴露了8081、5001这两个端口，并通过NFS对配置文件、日志和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对nexus进行访问。其中，5001作为docker私有镜像仓库的端口。

#------------------------定义Nexus代理服务-------------------------
apiVersion: v1
kind: Service
metadata:
  name: nexus3
spec:
  type: NodePort
  ports:
  # Port上的映射端口
  - port: 8081
    targetPort: 8081
    name: nexus8081
  - port: 5001
    targetPort: 5001
    name: nexus5001
  selector:
    app: nexus3
---
#-----------------------定义Nexus部署-------------------------
apiVersion: apps/v1beta2
kind: Deployment
metadata:
   name: nexus3
   labels:
     app: nexus3
spec:
   replicas: 1 #副本数为3
   selector: #选择器
     matchLabels:
       app: nexus3 #部署通过app：nginx标签选择相关资源
   template: #Pod的模板规范
     metadata:
       labels:
         app: nexus3 #Pod的标签
     spec:
       imagePullSecrets:
       - name: devops-repo
       containers: #容器
       - name: nexus3
         image: sonatype/nexus3
         imagePullPolicy: IfNotPresent
         ports: #端口
         - containerPort: 8081
           name: nexus8081
         - containerPort: 5001
           name: nexus5001
         volumeMounts:
         - name: nexus-persistent-storage
           mountPath: /nexus-data
       volumes:
       # 宿主机上的目录
       - name: nexus-persistent-storage
         nfs:
           server: 192.168.8.150
           path: /k8s-nfs/nexus

通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署nexus：

$ kubectl create -f {path}/nexus.yaml

2.3 流水线工具-Jenkins

2.3.1 jenkins安装部署

在本文的devops方案中，采用jenkins作为流水线工具。下面是在Kubernetes中部署jenkins的YAML配置文件，在此文件中定义了jenkins部署和服务。jenkins部署使用的镜像为lw96/java8-jenkins-maven-git-vim:latest，并暴露了8080这个端口，并通过NFS对配置文件和数据进行持久化。在服务中，端口的类型为NodePort，即允许集群外的用户可以通过映射在主机节点上的端口对jenkins进行访问。另外，在此镜像中也提供maven和java。

#------------------------定义代理服务-------------------------
apiVersion: v1
kind: Service
metadata:
  name: jenkins-devops
spec:
  type: NodePort
  ports:
  # Port上的映射端口 
  - port: 8080
    targetPort: 8080
    name: pipeline8080
  selector:
    app: jenkins-devops
---

# ------------------------定义mysql的部署 -----------------------
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: jenkins-devops
spec:
  selector:
    matchLabels:
      app: jenkins-devops
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: jenkins-devops
    spec:
      containers:
      # 应用的镜像
      - image: 10.0.32.148:1008/lw96/java8-jenkins-maven-git-vim
        name: jenkins-devops
        imagePullPolicy: IfNotPresent
        # 应用的内部端口
        ports:
        - containerPort: 8080
          name: pipeline8080 
        volumeMounts:
        # jenkins-devops持久化
        - name: pipeline-persistent
          mountPath: /etc/localtime
        # jenkins-devops持久化
        - name: pipeline-persistent
          mountPath: /jenkins
        # jenkins-devops持久化
        - name: pipeline-persistent-repo
          mountPath: /root/.m2/repository
        - name: pipeline-persistent-mnt
          mountPath: /mnt
      volumes:
      # 使用nfs互联网存储
      - name: pipeline-persistent
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/jenkins-devops
      - name: pipeline-persistent-mnt
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/jenkins-devops/mnt
      - name: pipeline-persistent-repo
        nfs:
          server: 192.168.8.150
          path: /k8s-nfs/jenkins-devops/repo

通过kubectl命令工具，执行如下的命令，在kubernetes集群中部署jenkins：

$ kubectl create -f {path}/jenkins-devops.yaml

注意，后续将执行下面的操作：

• 将Kubernetes集群的kubeconfig文件拷贝到192.168.8.150主机的/k8s-nfs/jenkins-devops/mnt目录下；
• 将maven的settings.xml文件拷贝至到192.168.8.150主机的/k8s-nfs/jenkins-devops/repo目录下；
• 将maven的依赖插件包拷贝至到192.168.8.150主机的/k8s-nfs/jenkins-devops/repo目录下。

3、 devops平台搭建

3.1 nexus设置

nexus在devops中承担两个功能，作为maven的远程仓库和作为docker的私有镜像仓库。

在本文中，使用nexus默认安装的maven-snapshots、maven-releases和maven-public这三个仓库。

并为docker创建一个名为registry的私有镜像仓库，其端口为5001：

3.2 maven设置

maven负责管理代码的依赖关系和构建。maven通过settings.xml文件设置运行环境，包括与远程仓库的连接。本文中的settings.xml如下所示，http://nexus3:8081中的nexus3是在kubernetes中的服务名称。将settings.xml拷贝至192.168.8.150机器的/k8s-nfs/jenkins-devops/repo目录下。

<?xml version="1.0" encoding="UTF-8"?>
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <pluginGroups>
  </pluginGroups>
  <proxies>
  </proxies>
  <servers>
     <server>     
      <id>maven-release</id>     
      <username>admin</username>     
      <password>admin123</password>     
    </server>     
    <server>     
      <id>maven-snapshots</id>     
      <username>admin</username>     
      <password>admin123</password>     
    </server>     
  </servers>

  <mirrors>
    <mirror>        
     <id>nexus</id>         
     <url>http://nexus3:8081/repository/maven-public/</url>        
     <mirrorOf>*</mirrorOf>        
   </mirror>     
 </mirrors> 

  <profiles>
  <profile>
      <id>maven-release</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
        <repository>
          <id>maven-release</id>
          <name>Repository for Release</name>
          <url>http://nexus3:8081/repository/maven-releases/</url>
     <releases>
     <enabled>false</enabled>
     </releases>
     <snapshots>
     <enabled>true</enabled>
     </snapshots>
        </repository>
      </repositories>
    </profile>

  <profile>
      <id>maven-snapshots</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <repositories>
        <repository>
          <id>maven-release</id>
          <name>Repository for Release</name>
          <url>http://nexus3:8081/repository/maven-snapshots/</url>
     <releases>
     <enabled>false</enabled>
     </releases>
     <snapshots>
     <enabled>true</enabled>
     </snapshots>
        </repository>
      </repositories>
    </profile>
  </profiles>
</settings>

3.3 docker设置

为了能够支持将远程提交的代码构建成镜像，以及将构建好的镜像上传至镜像仓库需要在/etc/docker/daemon.json的文件中添加下面的内容。其中，10.0.32.163:32476为镜像仓库的地址和端口，tcp://0.0.0.0:4243为对外暴露的地址和端口。

{
"hosts":["tcp://0.0.0.0:4243","unix:///var/run/docker.sock"],
"insecure-registries":["10.0.32.163:32476"]
}

并通过执行下面的命令重启docker服务：

$ systemctl daemon-reload
$ systemctl restart docker

3.4 jenkins设置

3.4.1 安装插件

jenkins作为devops平台的流程线工具，需要从gitlab中获取代码，并提交给maven进行构建；在代码构建成功后，调用docker构建镜像，并将上传至基于Nexus的私有镜像仓库；最终，在Kubernetes中部署和运行镜像。为了实现上述能力，需要在jenkins中安装如下插件：

• git plugin：与gitlab集成的插件，用于获取代码；
• maven plugin：与maven集成的插件，用于构建代码；
• CloudBees Docker Build and Publish plugin：与docker集成的插件，用于构建docker镜像，并上传至镜像仓库；
• Kubernetes Continuous Deploy Plugin：与kubernetes集成的插件，用于将镜像部署到kubernetes环境。

3.4.2 maven设置

在jenkins中的“全局工具配置”页面，设置maven的安装信息，name可以按照自己的喜好填写，MAVEN_HOME为maven的安装地址，此处为/opt/maven。

4、devops持续集成示例

1）安装git客户端和创建密钥

在工作计算上安装git客户端，并通过下面的命令创建ssh密钥：

ssh-keygen -t rsa -C "your.email@example.com" -b 4096

执行上述命令后，会在本地的～/.ssh目录创建id_rsa.pub(公钥)和id_rsa(私钥)。

2）在gitlab创建oms项目

进入gitlab，并创建一个名称为oms的项目。

在gitlab中添加所创建的公钥：

3）在eclipse中进行代码开发

在eclipse中创建类型为maven的oms项目，并进行代码开发。在完成代码开发后，将代码上传至gitlab中进行代码托管。

4）在jenkins中创建oms项目

进入jenkins，创建一个名称为oms的maven项目。

5）在jenkins中设置获取代码信息

在jenkins中，进入oms的配置页面，在源代码管理处设置获取源代码的相关信息。

• Repository URL：项目在gitlab中的地址；
• Credentials：访问gitlab的认证方式；
• Branch Specifier：代码的分支。

此处访问gitlab的认证方式为“SSH Username with private key”，Private Key的值来自于～/.ssh目录下id_rsa(私钥)的内容。

6）在jenkins中设置构建和上传镜像信息

在oms项目的配置的“Docker Build and Publish”部分，填写如下的信息；

• Repository Name：镜像的名称；
• Tag：镜像的版本；
• Docker Host URI：docker服务的地址和端口；
• Docker registry URL：docker镜像仓库的地址；
• Registry credentials：镜像仓库的认证方式。

7）在jenkins中设置部署容器信息

在oms项目的配置的“Deploy to Kubernetes”部分，填写如下的信息；

• Kubernetes Cluster Credentials：Kubernetes集群的认证方式；
• Path：kubeconfig文件的所在地址；
• Config Files：构建YAML配置文件。

8）在jenkins中执行oms构建

在oms项目创建和设置完成后，可以对项目进行构建操作。通过一键操作，jenkins将会完成从构建、打包成镜像和部署的所有工作内容：

• 从gitlab中获取oms的代码；
• 提交给maven进行构建；
• 调用docker构建镜像；
• 上传镜像至Nexus的私有镜像仓库；
• 部署镜像到kubernetes集群。

9）在kubernetes中查看部署情况

进入kubernetes(本文使用的为Rancher系统)界面，在default命名空间下，可以看到已部署的oms。

参考材料

1.《User documentation》地址：http://10.0.32.163:32269/help/user/index.md

2.《CloudBees Docker Build and Publish plugin》地址：https://wiki.jenkins.io/display/JENKINS/CloudBees+Docker+Build+and+Publish+plugin

3.《Kubernetes Continuous Deploy Plugin》地址：https://wiki.jenkins.io/display/JENKINS/Kubernetes+Continuous+Deploy+Plugin

作者简介：
季向远，北京神舟航天软件技术有限公司产品经理。本文版权归原作者所有。

微信公众号：ik8s

以下是本次分享的实录：

杨乐：非常感谢大家，在这个天气炎热的周六来到这里。在这里给大家带来的是关于 PaaS 云平台在企业中落地的经验分享，其中包括了生产环境中关注的问题，Kubernetes 的架构和资源对象的利用，以及我们在实际实施过程中遇到的一些问题。另外 PaaS 平台体系构建完成，是如何在容器云上进行的应用实践的，以及我们基于 Docker、Kubernetes 所构建 DevOps 体系持续集成，测试环境和生产环境是如何应用 Kubernetes 去构建运行使用的，我们还会介绍微服务治理相关的架构，以及我们部署架构的知识。

在 PaaS 云平台落地的时候，会有一些关注点，我们在企业落地实施的过程中，首先关注架构运行的方式，也就是说我们最初架构的选型，以及它的核心组件，比如说我们的日志如何去收集，监控和报警组件是如何运行的。在 PaaS 平台上运行的应用，相关的应用服务是如何发布出去的，是以何种方式代理出去的。以及我们在落地实施的时候，平台自身的组件以及 Kubernetes 本身的组件如何实现它的高可用，真正实现生产运行体系。

为了运行有状态应用，需要分布式存储进行支持。如何构建集群的网络类型，如何将容器服务进行集群内的网络打通。持续集成体系是我们基于 Kubernetes 相关的资源对象去构建的开发测试运维一体化的子产品。而最终要去注重用户应用的发布、运行，同时需要以容器的方式在部署到 PaaS 平台，如何将应用容器进行互联。

我们会关注真正落地实施之后，从它的架构运营、高可用性，到最终成体系的构建、应用的部署。而这几个关键点，会在后面每一个对应到 Kubernetes 架构体系上，一一介绍。

在场的各位对 Docker 和 Kubernetes 有没有一些了解，Docker  是单机容器的运行引擎。而 Kubernetes 是将容器以及 Docker 做集群架构的体系，它的架构方式是 Master、Slave 的方式。也就是说 Master 作为中控调动中心，去控制我的 Slave 结点。而 Slave 节点上面，所有的这些结点去运行相关的容器。应用服务都会用容器的方式运行在 Slave 节点之上。而它的发布是通过 Service 以及外部代理的方式向外发布。而每一个容器可以通过设置后端存储的方式进行持久的存储。

在 Kubernetes 组件里，需要关注日志组件。当容器运行在 Kubernetes 架构体系的时候，我需要关心应用本身产生的日志有没有问题。测试和开发人员需要获取一些调试的信息，然后去判断它的问题在哪里。而运维人员也需要查看发生问题的应用，它的日志在哪里。

当容器的 CPU 或者是内存发生了一些变动，超出负载的阈值时，需要做及时的报警。在内网进行服务发现的时，需要一个 DNS 的配置，以此各个应用间可进行探测和调用。

我们后面会有一些存储和网络，网络需要支持我们整个集群之内所有的结点，容器之间需要网络的打通，可以让容器在内网之间做一个互联，做一个架构的连接。

运维人员和开发人员可以通过可视化的展示组件去检索对应的日志。对于日志来说，Docker logs 是默认的日志输出的位置。但是通过一些特定的设置，不单单可以收集 Docker logs 本身产生的日志，还能够指定应用所能够达到日志的位置，指定相关的目录，并能够随意收集容器内部日志的信息。

在监控体系方面，第一种方式，Kubernetes 本身是使用 Kubelet 以及 Heapster、Influxdb 构建的。Influxdb 会把相关监控信息存储起来，监控数据从kubelet中通过heapster远程获取的。通过 Grafana 去展示相关的监控信息。用户通过一个集中化监控展示平台，可以查看到指定的容器服务所用的 CPU、内存相关的监控信息。

第二种监控体系是使用 Prometheus 组件，这两种体系是分别独立的。它的方式也是通过收集每一个节点相关的 CPU、内存等等监控信息，存储到一个中心化存储体系里面去，然后再把相应的监控信息展示出来。

对于报警体系，可以通过 Prometheus 本身的一些规则的设置，可以设置达到我 CPU 预值20% 的时候会触发报警事件。它可以调用外部相关操作的动作，比如说调用我们的平台，调用我们平台 API 里面所集成的短信或者邮件 API。就可实现从我们平台发生的监控，比如说超过了预值的 CPU，自动发出报警给我们的管理员，管理员就可以在及时检测到CPU、容器以及节点它的问题所在。

Kubernetes 一个核心组件就是 kube-DNS，它是为 Kubernetes 内部应用之间做服务发现。什么是服务发现，当我们把我们的应用去运行到 Kubernetes 体系里面去的时候，每一个应用中需要有一定的机制发现对方。我需要知道我周围的这些应用运行的名字是什么，它的运行位置在哪里，它的 IP 是多少。我需要这样一套发现机制，而 Kubernetes 本身提供的一方面把每一个应用和容器的信息记录到 Master 里面去。同时用 Kubernetes DNS 的方式展现给其它的应用工具。

当用户创建应用后，会在内网 kube-dns 里面记录一个域名。 每一个域名对应我一个应用，当其它的应用容器想要连接指定的应用的时候，只需要通过 DNS 域名就可以连接到。DNS 的 Kubedns 组件，不停的跟 Master Apiserver 进行交互，实时获取所创建或者是删除的这些应用的状态，获取IP地址、名称，并记录在 DNS 存储空间里，形成一条条 DNS 记录。而 DNS 会把相应的记录信息整合成DNS的服务出口。这样其它的应用服务可以通过DNS的53端口，进行查询，和DNS记录检索。这样就实现在整个联网范围之内，通过DNS去查询到指定的应用服务的功能。

Kube-DNS 是可以应用到 Kubernetes 本身的编排体系里面去。也就是说当我们运行应用到Kubernetes 架构体系里面之后，它不单是一个应用，而是多应用需要编排在一起。编排在一起就需要每一个应用互相之间进行一个发现和连接，而连接就需要用IP地址或者是域名，这里面就是用域名的方式。

所以我在编排的时候，通过一个编排文件，把编排文件每一个应用之间，它是用域名的方式设计到里面去。通过编排文件它可以统一的创建所有的应用，让它同时去启动或者是顺序启动，进行一个架构的建设。

高可用性，高可用对于系统平台来说，包括 Kubernetes 本身的高可用，还有我们提供自身产品的高可用，还有各种其它组件和存储的高可用。Kubernetes 本身高可用提供的这种方式，首先 Master高可用，Master 高可用通过多个 Master 的方式让它多活，然后通过统一的 Keepalived 的方式跟 Service 进行一个互联。

而相应的服务对外发布出口的时候，需要有一个对外的出口。底层存储的方式是通过多活的方式进行高可用的设置。平台本身每一个涉及到单点故障问题的组件都设置了高可用性，这个也是在生产环境中必要考虑的。

而 Service 这个概念就是一个抽象的服务出口，这就是为了将我的 Pod 或者是我的容器运行在 Kubernetes 之后，如何将它发布出去，如何让用户从外部进行一个访问，让 Service  做这件事情，它实际上是在我们的节点上做了一个负载均衡器。一个基于 IOS 一个负载均衡器。它会把用户外部访问的流量分发到内部多个 Pod 或者是容器上面进行一个负载均衡。

Labels 实际上是指在我 Kubernetes 本身资源对象里面作为一个标签，以及标签选择的方式。

ConfigMap 实际上是对数据的管理，我可以通过把我的一些外部配置信息放在 Kubernetes  存储里面的一种方式。然后去解决我在构建完我的容器进项之后，我希望把我的这些进项放在不同的环境里面，而不同的环境外部配置信息反而不一样。而我又不希望更改我容器里面的这些内容。那就用外部的方式，将外置的配置信息加载到容器里面。

而这个 ConfigMap 就起外部配置信息加载到容器里面的作用的。Secret 本身是解决密码以及 token 相关的问题。Job 是任务以及定时任务，我可以设置一个应用程序或者是一个进程让它运行一次，或者我可以设置定时进行。这些可以把它思考成一个 cronjob，也就是说一些定时任务会去做。

水平伸缩也就是说 HPA，在 Kubernetes 里面，它可以做到应用容器的一些自动伸缩。可以根据我们的 CPU 或者是内存、网络或者是磁盘 AIO，它的参数，进行一个实例的伸缩。如果我们设置了一个预值，如果 CPU 超过了 50%，那么我的容器自动扩展到 10 个或者是 20 个。当 CPU 低于百分之多少的时候，我可以让他自动回缩到指定的数量。这就是在负载变化的情况下，对实例伸缩的功能。

而下面的 Stateful、Volumes 以及 Ingress，Stateful 是为了解决有状态服务，以及可以做集群模式对象。Volumes 是为了解决相关磁盘存储，还有 Ingress 是 Kubernetes 本身指定的负载均衡代理。

对于 Kubernetes 资源对象 Stateful 首先是为了解决有状态存储的一些应用。如果需要手动设置多个 Pod 之间的存储配置，就会出现一个问题，Pod 重启之后就消失了。所以如果我们手动配置的话，就很难做到他们之间主从的配置

而 Stateful 是为了解决这个问题，Stateful 第一个特点是可以挂载相应的动态存储。第二他可以将起来的这些 Pod 进行有序的标号，也就是说普通的 Pod 的话，它的标号是随机的。但是这种 Stateful 是有序的，从 0 开始一直到 N 为止。也就是说这几个 Pod 之间是可以用有序的名字互相发现。这就带来一个可能，我在运行 Stateful 的时候，我可以设置一些参数或者是脚本，让他们按照这个名字互相发现。这样你通过互相发现的方式，再进行主从之间一些动态设置。这就可以实现我起了多个容器，通过 Stateful 进行一些动态设置。他们可以完成主从，进行集群的配置。也就是说 Stateful 可以实现各个需要进行主从配置应用软件的集群设置。

Ingress 我们之前提到作为一个服务出口，当我们的应用运行在 Kubernetes 的时候，我们需要把它进行对外的发布，发布的方式可以通过代理的方式，也可以通过 Ingress 的方式。

实际上 Ingress 对应的就是我们所关注的服务出口的问题，而 Ingress 是解决出口的方式之一，实际上还有其它很多种方式，也可以自研去做这个事情。

Volumes 是解决整个 PaaS 平台它的存储问题，我们应用容器在运行的时候，如果我们用过 Kubernetes，如果 Pod 起来以后，如果不进行持久化存储的话，重启以后很多内容丢失。为了防止关键信息丢失，我们需要挂在分部式的存储。

一种方式就是我们通过 PVC 的方式，挂在一些文件体系上面。这样 Pod 在进行迁移的时候，其中一个 Pod 在机器上挂掉以后。它的存储会跟随我们的 Pod 从另外一个可用的机器上起来。这样的话，它原来的内容可以在新的 Pod 里面读取到，这样就达到存储可用性的效果。

Kubernetes 网络类型也有很多种方式，现在我们常用或者是我们现在支持的方式就是包括让 Calico、Flannel、Weave 的方式。实际上一种是隧道的方式，或者是用路由的方式去实现。

从上图我们可以看到生产环境实施的整个架构模式图，首先对于 Kubernetes 来说，整个集群各个组件模块是需要多副本的，整个控制台对 API 调用的控制端需要多个节点，以及镜像仓库、文件存储，以及相关的 Slave 都是需要多节点的。

而在集群内部，需要一组服务出口。在应用的时候，持续集成所需要运行一组集群，这些都需要高可用去做。每一个功能组件，可以通过一种方式进行合理的分组。每种类型的组件或者应用，可以运行到指定的服务器节点上去。

 而 Kubernetes 本身部署起来，可以是虚拟机，也可以是物理机，也就是说它的底层架构可以是偶合的。

通过 Kubernetes job 的方式来进行持续集成，也就是说持续集成构建的框架。通过这个框架，我们启动我们的持续集成的时候，我们会调动 API。通过 job 的方式，启动多个构建服务，每一个 job 对应一个任务去完成它指定的工作。当它完成以后，会通过代码的构建以及镜像的生成。结束以后，它会把相应的镜像放在指定的镜像仓库里面去。。

通过对镜像仓库以及 API 的设置，它可以自动从镜像仓库里再次部署到 Kubernetes 的环境里面。

开发人员可以通过代码提交的方式去触发持续集成。同时进行单元测试。测试结束之后做一些审计，然后把这些结果发送。扫描结束之后会对它进行一个编辑，编译的结果会传到下一步里面，进行一个代码构建，代码构建会生成相应的镜像，它会推送到我的镜像中心，然后会接受一些安全扫描。扫描镜像里面是否存在一些安全风险，它有没有一些漏洞。在漏洞扫描结束之后，会经过部门的审批流程。如果部门审批流程通过，它就可以进行下一个镜像发布或者是发布到我们的平台，或者是让它上传到我们的应用商店里面。

这样当镜像进行一个发布之后，会运行到测试环境，可以交给测试团队进行一个部署的测试。当测试团队发现问题之后，会交给开发人员进行再一次迭代。这样就会形成从研发体系到代码提交到研发开发测试，到最终的部署运行以及再次回环的迭代，整个回环体系就构建起来了。

这是测试环境以及生产环境的运行体系，在给客户部署实施的时候，一般情况下，很多用户都是按不同的部门或者是按不同的网络环境的多个集群。在这个图上可以看到左边是测试环境集群，也就是说这是一套独立的 Kubernetes 集群体系，右边是生产环境的一些集群。这里面是所有生产环境的应用都在运行。

从构建体系来说，持续集成体系可以在这里面跑。也就是说从代码的生成到持续集成部署到镜像生成，自动把业务应用上去，开发测试人员通过测试环境对它进行一个测试。最终当测试完毕之后，这些镜像可以通过定版的方式同步到生产环境的镜像中心里面。

然后再通过运维或者是项目经理的管理，进行一个生产环境的部署。这样的话它就形成整套从生产环境到测试环境整体的运维体系。当我们在真正生产运维的时候，可以通过生产环境中的日志管理、监控管理、审计系统，通过这些组件进行生产环境的运维。

微服务治理是基于 Kubernetes 的特性基础上，将 SpringCloud 架构结合在一起。集成了  SpringCloud 的服务发现、负载均衡、配置管理等组件，可以用容器的方式运行到  Kubernetes 平台里面。用户可以把基于 springboot 开发的应用运行到平台里面，运行上去之后，应用将注册到服务注册中心，并可使用 SpringCloud 的相关组件。

生产环境落地实施后，最终要实现的是用户的应用要上云，真正的部署上去。部署的环节需要首先把应用程序进行容器化。需要构建应用的生产环境，将应用程序进行打包，然后将应用的镜像部署到我们的 Kubernetes 里，让 Kubernetes 对应用程序进行生命周期的管理，当整个架构体系和服务体系上云以后，可以进行多个组件之间的编排，组件直接进行互联，并且通过配置管理进行相同应用多个环境的部署。

当涉及到数据库的存储时，需要使用 Stateful 对象进行管理。当应用架构部署完成以后，对外发布的时候，需要进行负载均衡出口的管理。最终以如图这种方式，通过负载均衡访问到 APP，以及数据存储通过存储块进行有状态保持，在运维的过程中，对其进行配置管理，以及监控、日志的查看、操作，这样一整套运维体系就可以构建起来。

Q&A

Q：用户隔离怎么做？

A：用户隔离是基于用户命名空间的体系做的网络隔离。Calico本身是负责网络隔离的，再就是一些用户体系的资源隔离，都可以通过kubernetes 的命名空间进行隔离。

Q：我刚才看有大数据相关的组件，我不知道你这边大数据有没有用到ES等性能要求比较高的应用。在这种情况下，你们的性能表现是什么样的。第二个问题是在Kubernetes有三种service模式，你这边是哪一种模式？

A：大数据相关的组件实际上如果你要运行的话，跟性能相关的，还是基于底层硬件体系。也就是说 Kubernetes 本身是需要架设在 IaaS 或者是物理基上的。如果说底层性能不够优的话，你构建那些 SDN 网络，它的性能也会受到连累。因为本身它访问的性能以及存储的性能，都是涉及到我用 ios 这种软件定义网络的方式去做的。最终是要打到物理环境里的。

第一建议网络做的比较优，再就是要用高性能，高 IO 的存储组件。

第二个问题是 Service，通过 Service nodeport 对外发布的时候，但是对于企业管理来说，你可能涉及到要发布到哪一个节点上，以及这些节点上的关口如何去管理。如果你这一套系统自用的话，这个方式是没有问题的。但是如果是一个企业或者是公有云，就会涉及到这些端口对于管理人员来说，管理起来是比较困难的。

所以最好集中的方式用这种指定节点，并且让它只是在几个节点上开端口的方式，或者是用 externalIP 这种方式做比较好。

历经5年发展，Docker公司揭露了今年最新的Docker年度数据报告，从2013年3月PyCon大会上，Docker首度亮相之后，至今在Docker上的容器镜像下载次数已经超过了370亿次，容器化的应用有高达350万个，目前在LinkedIn网站上的Docker相关职缺也有15,000个。全球活跃的Docker使用者社群已有200多个，包括台湾也有。全球使用企业版Docker EE的企业顾客目前则约有450家。

而过去一年，Docker功能的进展不多，主要有拥抱Kubernetes，在Docker产品中可以和Swarm并用。其次最重要的新功能是增加了RBAC角色存取控管机制，这也是企业最想要的安全机制。另外Docker也推出了传统应用MTA计划，提供一个企业将老旧应用容器化的建议方法。