达观数据：kubernetes简介和实战

在本文中，我们从技术细节上对 kubernetes 进行简单运用介绍，利用一些 yaml 脚本层面上实例告诉大家 kubernetes 基本概念。 Kubernetes 以及它呈现出的编程范式值得你去使用和整合到自己的技术栈中。

kubernetes简单介绍

1

kubernetes 起源

Kubernetes 最初认为是谷歌开源的容器集群管理系统，是 Google 多年大规模容器管理技术 Borg 或 Omega 的开源版本。准确来说的话， kubernetes 更是一个全新的平台，一个全新的平台管理工具，它是专门为 job 和 service 设计。完全开放， 2014 年 6 月开始接受公开的 commit ，任何人都可以提供意见。由于 kubernetes 简化了开发、运维和管理负荷，越来越多的企业开始在生产环境使用，因此 kubernetes 得到了迅速的发展。

2

kubernetes 功能

• 基于容器的应用部署、维护和滚动升级

• 负载均衡和服务发现

• 跨机器和跨地区的集群调度

• 自动伸缩

• 无状态服务和有状态服务

• 广泛的 Volume 支持

• 插件机制保证扩展性

3

kubernetes 核心组件

Kubernetes 主要由以下几个核心组件组成：

• etcd 保存了整个集群的状态；

• apiserver 提供了资源操作的唯一入口，并提供认证、授权、访问控制、 API 注册和发现等机制；

• controller manager 负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；

• scheduler 负责资源的调度，按照预定的调度策略将 Pod 调度到相应的机器上；

• kubelet 负责维护容器的生命周期，同时也负责 Volume （ CVI ）和网络（ CNI ）的管理；

• Container runtime 负责镜像管理以及 Pod 和容器的真正运行（ CRI ）；

• kube-proxy 负责为 Service 提供 cluster 内部的服务发现和负载均衡

kubernetes环境部署

如果只是为了了解 kubernetes ，可以使用 minikube 的方式进行单机安装， minikube 实际就是本地创建了一个虚拟机 , 里面运行了 kubernetes 的一些必要的环境 , 相当于 k8s 的服务环境 , 创建 pod,service,deployment 等都是在里面进行创建和管理。在本文中，我使用 kubeadm 方式安装 kubernetes 1.10.0 ，具体 kubernetes 部署步骤：

• 使用 kubeadm 方式安装 kubernetes 1.10.0

• Kubernetes 集群添加／删除 Node

• Kubernetes Dashboard1.8.3 部署

• k8s 原生的集群监控方案（ Heapster+InfluxDB+Grafana)

请注意：上述环境只是测试环境，生产环境部署大同小异。

kubernetes基本概念

1

Container

Container （容器）是一种便携式、轻量级的操作系统级虚拟化技术。 它使用 namespace 隔离不同的软件运行环境，并通过镜像自包含软件的运行环境，从而使得容器可以很方便的在任何地方运行。由于容器体积小且启动快，因此可以在每个容器镜像中打包一个应用程序。这种一对一的应用镜像关系拥有很多好处。

使用容器，不需要与外部的基础架构环境绑定 , 因为每一个应用程序都不需要外部依赖，更不需要与外部的基础架构环境依赖，完美解决了从开发到生产环境的一致性问题。 容器同样比虚拟机更加透明，这有助于监测和管理。 尤其是容器进程的生命周期由基础设施管理，而不是由容器内的进程对外隐藏时更是如此。最后，每个应用程序用容器封装，管理容器部署就等同于管理应用程序部署。在 Kubernetes 必须要使用 Pod 来管理容器，每个 Pod 可以包含一个或多个容器。

2

Pod

关于 Pod 的概念主要有以下几点：

• Pod 是 kubernetes 中你可以创建和部署的最小也是最简的单位。一个 Pod 代表着集群中运行的一个进程；

• 在 Kubrenetes 集群中 Pod 的使用方式；

• Pod 中如何管理多个容器

理解 Pod:

上面已经说了 “Pod 是 kubernetes 中你可以创建和部署的最小也是最简的单位。 一个 Pod 代表着集群中运行的一个进程。 ” Pod 中封装着应用的容器（有的情况下是好几个容器） , 存储、独立的网络 IP ，管理容器如何运行的策略选项。

Pod 代表着部署的一个单位： kubernetes 中应用的一个实例，可能由一个或者多个容器组合在一起共享资源。

请注意： Docker 是 kubernetes 中最常用的容器运行时，但是 Pod 也支持其他容器运行时。

Kubrenetes 集群中 Pod 的两种使用方式：

（ 1 ）一个 Pod 中运行一个容器 “ 每个 Pod 中一个容器 ” 的模式是最常见的用法；在这种使用方式中，你可以把 Pod 想象成是单个容器的封装， kuberentes 管理的是 Pod 而不是直接管理容器 。

实战：创建一个 nginx 容器

apiVersion: v1
kind: Pod
metadata:
name:nginx-test
labels:
app: web
spec:
containers:
- name:front-end
image:nginx:1.7.9
ports:
-containerPort: 80

创建Pod：
kubectl create -f ./pod1-deployment\
查看Pod ：
kubectl get po
查看Pod详细情况：
kubectl describe po nginx-test

进入到Pod（容器）内部：

kubectl exec -it nginx-test  /bin/bash

（ 2 ）在一个 Pod 中同时运行多个容器

说明：在一个 Pod 中同时运行多个容器是一种比较高级的用法。只有当你的容器需要紧密配合协作的时候才考虑用这种模式。

一个 Pod 中也可以同时封装几个需要紧密耦合互相协作的容器，它们之间共享资源。这些在同一个 Pod 中的容器可以互相协作成为一个 service 单位 —— 一个容器共享文件，另一个 “sidecar” 容器来更新这些文件。 Pod 将这些容器的存储资源作为一个实体来管理。

实战：在一个 pod 里放置两个容器： nginx 与 redis

apiVersion: v1
kind: Pod
metadata:
name: rss-site
labels:
app: web
spec:
containers:
- name:front-end
image:nginx:1.7.9
ports:
-containerPort: 80
- name:rss-reader
image: redis
ports:
-containerPort: 88

创建 Pod ：
kubectl create -f ./test-deployment
查看 pod
kubectl get po
查看 Pod 详细情况
kubectl describe po rss-site
进入 front-end 内部：
kubectl exec -it rss-site  -c front-end /bin/bash
进入 rss-reade 内部：
kubectl exec -it rss-site  -c rss-reader /bin/bash

以上是关于 Pod 的简单介绍。

3

Node

Node 是 Pod 真正运行的主机，可以物理机，也可以是虚拟机。为了管理 Pod ，每个 Node 节点上至少要运行 container runtime （比如 docker 或者 rkt ）、 kubelet 和 kube-proxy 服务。

4

Namespace

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

5

Deployment

我们既然有 Pod 了，为什么还要使用 Deployment 呢？这是因为实际工作中，我们很少会直接在 kubernetes 中创建单个 Pod 。因为 Pod 的生命周期是短暂的，用后即焚的实体。 Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。 你只需要在 Deployment 中描述想要的目标状态是什么， Deploymentcontroller 就会帮你将 Pod 和 ReplicaSet 的实际状态改变到你的目标状态。你可以定义一个全新的 Deployment 来创建 ReplicaSet 或者删除已有的 Deployment 并创建一个新的来替换。

什么是复制控制器（ ReplicationController ， RC ）

RC 是 K8s 集群中最早的保证 Pod 高可用的 API 对象。通过监控运行中的 Pod 来保证集群中运行指定数目的 Pod 副本。指定的数目可以是多个也可以是 1 个；少于指定数目， RC 就会启动运行新的 Pod 副本；多于指定数目， RC 就会杀死多余的 Pod 副本。即使在指定数目为 1 的情况下，通过 RC 运行 Pod 也比直接运行 Pod 更明智，因为 RC 也可以发挥它高可用的能力，保证永远有 1 个 Pod 在运行。 RC 是 K8s 较早期的技术概念，只适用于长期伺服型的业务类型，比如控制小机器人提供高可用的 Web 服务。

什么是副本集（ Replica Set ， RS ）

RS 是新一代 RC ，提供同样的高可用能力，区别主要在于 RS 后来居上，能支持更多种类的匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。

Deployment 典型的应用场景

• 定义 Deployment 来创建 Pod 和 ReplicaSet

• 滚动升级和回滚应用；如果当前状态不稳定，回滚到之前的 Deployment revision 。每次回滚都会更新 Deployment 的 revision

• 扩容和缩容，扩容 Deployment 以满足更高的负载

• 暂停和继续 Deployment ，暂停 Deployment 来应用 PodTemplateSpec 的多个修复，然后恢复上线

实战 Deployment

比如，我们这里定义一个简单的 nginx 应用：

apiVersion:extensions/v1beta1
kind: Deployment
metadata:
name:nginx-test
namespace:test
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
-name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80

创建 deploy
kubectl create -f ./nginx-deployment
查看 deploy
kubectl get deploy --namespace=test
查看 rs （副本集）
kubectl get rs --namespace=test
查看 pods （容器组）
kubectl get po --namespace=test

关于 Deployment 的应用还有很多，如：扩容、缩容、滚动升级、回滚应用等，这里由于篇幅的问题不再一一介绍。

5

Label

Label 是识别 Kubernetes 对象的标签，以 key/value 的方式附加到对象上（ key 最长不能超过 63 字节， value 可以为空，也可以是不超过 253 字节的字符串）。

Label 不提供唯一性，并且实际上经常是很多对象（如 Pods ）都使用相同的 label 来标志具体的应用。 Label 定义好后其他对象可以使用 Label Selector 来选择一组相同 label 的对象（比如 ReplicaSet 和 Service 用 label 来选择一组 Pod ）。 Label Selector 支持以下几种方式：

• 等式，如 app=nginx 和 env!=production

• 集合，如 env in(production, qa)

• 多个 label （它们之间是 AND 关系），如 app=nginx,env=test

6

Service Account

Service account 作用

Service account 是为了方便 Pod 里面的进程调用 Kubernetes API 或其他外部服务。

Serviceaccount 使用场景

运行在 pod 里的进程需要调用 Kubernetes API 以及非 Kubernetes API 的其它服务。 Service Account 它并不是给 kubernetes 集群的用户使用的，而是给 pod 里面的进程使用的，它为 pod 提供必要的身份认证。

与 User account 区别

• User account 是为人设计的，而 service account 则是为了 Pod 中的进程

• User account 是跨 namespace 的，而 service account 则是仅局限它所在的 namespace

实战命名空间

apiVersion: v1
kind: Namespace
metadata:
name:datagrand
labels:
name: test

创建 namespace ： test
kubectl create -f ./test.yaml
查看命名空间 test 的 sa
kubectl get sa -n test
查看命名空间 test 生成的 default
kubectl get sa default -o yaml -n test
我们可以创建 Deployment 时，使用这个 test 命名空间了，如上例 Deployment 实战。

Service Account 鉴权

Service Account 为服务提供了一种方便的认知机制，但它不关心授权的问题。可以配合 RBAC 来为 Service Account 鉴权：

• 配置 --authorization-mode=RBAC 和 --runtime-config=rbac.authorization.k8s.io/v1alpha1

• 配置 --authorization-rbac-super-user=admin

• 定义 Role 、 ClusterRole 、 RoleBinding 或 ClusterRoleBinding

实战鉴权

我们在 Kubernetes Dashboard1.8.3 部署中，碰到首次登入出现访问权限报错的问题，原因就是 ServiceAccount 的创建问题。

apiVersion:rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name:kubernetes-dashboard
labels:
k8s-app: kubernetes-dashboard
roleRef:
apiGroup:rbac.authorization.k8s.io
kind:ClusterRole
name:cluster-admin
subjects:
- kind:ServiceAccount
name:kubernetes-dashboard
namespace:kube-system

7

Secret

Secret 介绍

Secret 解决了密码、 token 、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec 中。 Secret 可以以 Volume 或者环境变量的方式使用。

Secret 类型

• Opaque(default) ：任意字符串， base64 编码格式的 Secret ，用来存储密码、密钥等

• kubernetes.io/service-account-token ：作用于 ServiceAccount ，就是 kubernetes 的 Service Account 中所说的。即用来访问 Kubernetes API ，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中

• kubernetes.io/dockercfg: 作用于 Docker registry ，用户下载 docker 镜像认证使用。用来存储私有 docker registry 的认证信息
  

实战 Opaque Secret 类型

Opaque 类型的数据是一个 map 类型，要求 value 是 base64 编码格式：
创建 admin 账户
echo -n "admin" | base64
YWRtaW4=
echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm

创建 secret.yaml
cat >> secrets.yml << EOF
apiVersion: v1
kind: Secret
metadata:
name:mysecret
type: Opaque
data:
password:MWYyZDFlMmU2N2Rm
username:YWRtaW4=

创建 secret
kubectl create -f secrets.yml

查看 secret 运行状态
kubectl get secret --all-namespaces

Secret 使用方式

• 以 Volume 方式

• 以环境变量方式

实战 Secret 使用 Volume 方式

apiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: wtf
spec:
volumes:
- name:secrets
secret:
secretName: mysecret
containers:
- image:nginx:1.7.9
name: nginx
volumeMounts:
- name:secrets
mountPath:"/etc/secrets"
readOnly:true
ports:
- name: cp
containerPort: 5432
hostPort:5432

说明：这样就可以通过文件的方式挂载到容器内，在 /etc/secrets 目录下回生成这个文件。

实战 Secret 使用环境变量方式

apiVersion:extensions/v1beta1
kind: Deployment
metadata:
name:wordpress-deployment
spec:
replicas: 2
template:
metadata:
labels:
app:wordpress
spec:
containers:
- name:"wordpress"
image:"wordpress:latest"
ports:
-containerPort: 80
env:
- name:WORDPRESS_DB_USER
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name:WORDPRESS_DB_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password

查看 Pod 运行状态
kubectl get po
NAME                                                         READY     STATUS   RESTARTS     AGE
wordpress-deployment-6b569fbb7d-8qcpg   1/1      Running   0                   2m
wordpress-deployment-6b569fbb7d-xwwkg   1/1      Running   0                 2m

进入容器内部查看环境变量
kubectl exec -itwordpress-deployment-694f4c79b4-cpsxw /bin/bash
root@wordpress-deployment-694f4c79b4-cpsxw:/var/www/html#env
WORDPRESS_DB_USER=admin
WORDPRESS_DB_PASSWORD=1f2d1e2e67df

8

ConfigMap

Configure 说明

ConfigMaps 允许你将配置文件、命令行参数或环境变量中读取的配置信息与 docker image 分离，以保持集装箱化应用程序的便携性。即 ConfigMapAPI 给我们提供了向容器中注入配置信息的机制。

理解 ConfigMaps 和 Pods

ConfigMap API 资源用来保存 key-value pair 配置数据，这个数据可以在 pods 里使用，或者被用来为像 controller 一样的系统组件存储配置数据。虽然 ConfigMap 跟 Secrets 类似，但是 ConfigMap 更方便的处理不含敏感信息的字符串。

注意： ConfigMaps 不是属性配置文件的替代品。 ConfigMaps 只是作为多个 properties 文件的引用。你可以把它理解为 Linux 系统中的 /etc 目录，专门用来存储配置文件的目录。

实战创建 ConfigMap

kind: ConfigMap
apiVersion: v1
metadata:
creationTimestamp: 2016-02-18T19:14:38Z
name:example-config
namespace:default
data:
example.property.1: hello
example.property.2: world
example.property.file: |-
property.1=value-1
property.2=value-2
property.3=value-3

data 一栏包括了配置数据， ConfigMap 可以被用来保存单个属性，也可以用来保存一个配置文件。配置数据可以通过很多种方式在 Pods 里被使用。 ConfigMaps 可以被用来：

• 设置环境变量的值

• 在容器里设置命令行参数

• 在数据卷里面创建 config 文件

9

Volum

为什么需要 Volume

容器磁盘上文件的生命周期是短暂的，这就使得在容器中运行重要应用时出现一些问题。比如，当容器崩溃时， kubelet 会重启它，但是容器中的文件将丢失 -- 容器以干净的状态（镜像最初的状态）重新启动。

其次，在 Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。 Kubernetes 中的 Volume 抽象就很好的解决了这些问题。

Volume 背景

Docker 中也有一个 volume 的概念，尽管它稍微宽松一些，管理也很少。在 Docker 中，卷就像是磁盘或是另一个容器中的一个目录。它的生命周期不受管理，直到最近才有了 local-disk-backed 卷。 Docker 现在提供了卷驱动程序，但是功能还非常有限（例如 Docker1.7 只允许每个容器使用一个卷驱动，并且无法给卷传递参数）。

Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所以，卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是， Kubernetes 支持多种类型的卷， Pod 可以同时使用任意数量的卷。要使用卷，需要为 pod 指定为卷（ spec.volumes 字段）以及将它挂载到容器的位置（ spec.containers.volumeMounts 字段）。

Volume 类型

Kubernetes 支持以下类型的卷：

awsElasticBlockStore 、 azureDisk 、 azureFile 、 cephfs 、 csi 、 downwardAPI 、 emptyDir 、 fc (fibre channel) 、 flocker 、 gcePersistentDisk 、 gitRepo 、 glusterfs 、 hostPath 、 iscsi 、 local 、 nfs 、 persistentVolumeClaim 、 projected 、 portworxVolume 、 quobyte 、 rbd 、 scaleIO 、 secret 、 storageos 、 vsphereVolume 等

K8S 的存储系统分类

K8S 的存储系统从基础到高级大致分为三个层次：普通 Volume ， Persistent Volume 和动态存储供应。

普通 Volume

最简单的普通 Volume 是单节点 Volume 。它和 Docker 的存储卷类似，使用的是 Pod 所在 K8S 节点的本地目录。

persistent volume

它和普通 Volume 的区别是什么呢？

普通 Volume 和使用它的 Pod 之间是一种静态绑定关系，在定义