2019-012-K8s实战之概念、部署、服务配置

K8s实战之概念、集群部署与服务配置

本文是对于 Kubernetes实战系列文章的提炼。

Kubernetes [koo-ber-nay’-tice]是Google基于Borg开源的容器编排调度引擎，其支持多种底层容器虚拟化技术，具有完备的功能用于支撑分布式系统以及微服务架构，同时具备超强的横向扩容能力；它提供了自动化容器的部署和复制，随时扩展或收缩容器规模，将容器组织成组，并且提供容器间的负载均衡，提供容器弹性等特性。作为CNCF（Cloud Native Computing Foundation）最重要的组件之一，可谓云操作系统；它的目标不仅仅是一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态。

设计理念

与一般的PaaS平台相比，K8s也是支持服务部署、自动运维、资源调度、扩缩容、自我修复、负载均衡，服务发现等功能，而其独特之处就是其对于基础设施层进行了较好的能力抽象。K8s并没有处理具体的存储、网络这些差异性极大的部分，而是做云无关，开始实现各类interface，做各种抽象。比如容器运行时接口（CRI）、容器网络接口（CNI）、容器存储接口（CSI）。这些接口让Kubernetes变得无比开放，而其本身则可以专注于内部部署及容器调度。

Kubernetes有类似于Linux的分层架构，如下图所示：

基础设施层：包括容器运行时、网络、存储等。
核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境。
应用层：部署（无状态、有状态应用、Job等）和路由（服务发现、负载均衡等）
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口层：kubectl命令行工具、客户端SDK以及集群联邦
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等外部生态以及CRI、CNI、CSI、镜像仓库、Cloud Provider、集群自身的配置和管理等内部生态。

Kubernetes中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是Kubernetes重要设计理念之一，即所有的操作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式操作在分布式系统中的好处是稳定，不怕丢操作或运行多次，例如设置副本数为3的操作运行多次也还是一个结果，而给副本数加1的操作就不是声明式的，运行多次结果就错了。

相对于命令式操作，声明式操作会更稳定且更容易被用户接受，因为该API中隐含了用户想要操作的目标对象，而这些对象刚好都是名词性质的，比如Service、Deployment、PV等；且声明式的配置文件更贴近“人类语言”，比如YAML、JSON。声明式的设计理念有助于实现控制闭环，持续观测、校正，最终将运行状态达到用户期望的状态；感知用户的行为并执行。比如修改Pod数量，应用升级/回滚等等。调度器是核心，但它只是负责从集群节点中选择合适的Node来运行Pods，显然让调度器来实现上诉的功能不太合适，而需要有专门的控制器组件来实现。

组件与对象

Kubernetes的各种功能都离不开它定义的资源对象，这些对象都可以通过API被提交到集群的Etcd中。API的定义和实现都符合HTTP REST的格式，用户可以通过标准的HTTP动词（POST、PUT、GET、DELETE）来完成对相关资源对象的增删改查。常用的资源对象，比如Deployment、DaemonSet、Job、PV等。API的抽象也意在这部分资源对象的定义。Kubernetes有新的功能实现，一般会创建新的资源对象，而功能也依托于该对象进行实现。

类别	名称
资源对象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
存储对象	Volume、PersistentVolume、Secret、ConfigMap
策略对象	SecurityContext、ResourceQuota、LimitRange
身份对象	ServiceAccount、Role、ClusterRole

这里我们选择几个关键对象进行介绍。

部署（Deployment）

部署表示用户对Kubernetes集群的一次更新操作。部署是一个比RS应用模式更广的API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级一个服务。滚动升级一个服务，实际是创建一个新的RS，然后逐渐将新RS中副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个更通用的Deployment来描述。以Kubernetes的发展方向，未来对所有长期伺服型的的业务的管理，都会通过Deployment来管理。

服务（Service）

RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。如果说Deployment是负责保证Pod组的正常运行，那么Service就是用于保证以合理的网络来连接到该组Pod。

一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。Service有三种类型：

ClusterIP：默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP。
NodePort：在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过 <NodeIP>:NodePort 来访问该服务。
LoadBalancer：在NodePort的基础上，借助Cloud Provider创建一个外部的负载均衡器，并将请求转发到 <NodeIP>:NodePort。

在Kubernetes集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是Kubernetes集群内部的负载均衡器。它是一个分布式代理服务器，在Kubernetes的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

集群部署

Kubernetes实战系列中我们介绍了Docker本地搭建，基于Ubuntu手动搭建集群以及基于Rancher快速搭建集群等方式。使用Rancher可以自动和可视化的完成Kubernetes集群的安装工作，省去的繁琐的人工安装过程，然您快速投入的业务开发中。

$ docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher

先在Master节点安装Rancher server、control、etcd和worker。选择网络组件为Flannel，同时在自定义主机运行命令中选择主机角色、填写主机的内网和外网IP。

我们需要将脚本复制到对应的机器上运行，然后Rancher将自动创建Kubernetes集群，并默认在80端口运行Web Server。添加Node节点时只需要在Rancher的Web界面上找到您刚安装的集群并选择【编辑集群】并选择节点角色为Worker即可增加一台Kubenretes集群节点。

Helm

Helm是由Deis发起的一个开源工具，有助于简化部署和管理Kubernetes应用。在本章的实践中，我们也会使用Helm来简化很多应用的安装操作。

在Linux中可以使用Snap安装Heml：

$ sudo snap install helm --classic

# 通过键入如下命令，在 Kubernetes 群集上安装 Tiller
$ helm init --upgrade

在缺省配置下，Helm会利用 “gcr.io/kubernetes-helm/tiller” 镜像在Kubernetes集群上安装配置Tiller；并且利用 “https://kubernetes-charts.storage.googleapis.com” 作为缺省的stable repository的地址。由于在国内可能无法访问 “gcr.io”, “storage.googleapis.com” 等域名，阿里云容器服务为此提供了镜像站点。请执行如下命令利用阿里云的镜像来配置Helm：

$ helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.5.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

# 删除默认的源
$ helm repo remove stable

# 增加新的国内镜像源
$ helm repo add stable https://burdenbear.github.io/kube-charts-mirror/
$ helm repo add stable https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

# 查看 Helm 源添加情况
$ helm repo list

Helm的常见命令如下：

# 查看在存储库中可用的所有 Helm Charts
$ helm search

# 更新 Charts 列表以获取最新版本
$ helm repo update

# 查看某个 Chart 的变量
$ helm inspect values stable/mysql

# 查看在群集上安装的 Charts 列表
$ helm list

# 删除某个 Charts 的部署
$ helm del --purge wordpress-test

# 为 Tiller 部署添加授权
$ kubectl create serviceaccount --namespace kube-system tiller
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
$ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

kubectl

信息检索

get命令用于获取集群的一个或一些resource信息。使用–help查看详细信息。kubectl的帮助信息、示例相当详细，而且简单易懂。建议大家习惯使用帮助信息。kubectl可以列出集群所有resource的详细。resource包括集群节点、运行的pod，ReplicationController，service等。

$ kubectl get [(-o|--output=)json|yaml|wide|go-template=...|go-template-file=...|jsonpath=...|jsonpath-file=...] (TYPE [NAME | -l label] | TYPE/NAME ...) [flags] [flags]

运行与管理

kubectl run和docker run一样，它能将一个镜像运行起来，我们使用kubectl run来将一个sonarqube的镜像启动起来。

$ kubectl run sonarqube --image=sonarqube:5.6.5 --replicas=1 --port=9000

deployment "sonarqube" created

# 该命令为我们创建了一个 Deployment
$ kubectl get deployment
NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
sonarqube   1         1         1            1           5m

我们也可以直接以交互方式运行某个镜像：

$ kubectl run -i --tty ubuntu --image=ubuntu:16.04 --restart=Never -- bash -il

K8s将镜像运行在Pod中以方便实施卷和网络共享等管理，使用get pods可以清楚的看到生成了一个Pod：

$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
sonarqube-1880671902-s3fdq   1/1       Running   0          6m

$ 交互式运行 Pod 中的某个命令
$ kubectl exec -it sonarqube-1880671902-s3fdq -- /bin/bash

kubectl可以用于删除创建好的Deployment与Pod：

$ kubectl delete pods sonarqube-1880671902-s3fdq
$ kubectl delete deployment sonarqube

kubectl通用可以基于Yaml文件进行应用的生命周期管理：

# 创建
$ kubectl create -f yamls/mysql.yaml

# 删除
$ kubectl delete -f yamls/mysql.yaml

# 同时创建多个
$ kubectl create -f yamls/

# 同时删除多个
$ kubectl delete -f yamls/

上下文切换

在K8s集群安装完毕之后，可以下载集群的配置文件到本地kubectl配置中：

mkdir $HOME/.kube
scp root@<master-public-ip>:/etc/kubernetes/kube.conf $HOME/.kube/config

然后可以来查看当前的上下文

$ unset KUBECONFIG
$ kubectl config current-context # 查看当前载入的上下文
$ kubectl config get-contexts # 浏览可用的上下文
$ kubectl config use-context context-name # 切换到指定上下文

服务配置

Kubernetes实战/典型应用一节中，我们介绍了许多常见的中间件的配置部署方式。这里以简单的HTTP服务器为例，介绍常见的服务配置流程。

Deployment & Service

在 K8s Boilerplates 中我们定义了简单的Nginx的部署与服务，分别用于集群构建与对外的服务暴露：

# nginx-deployment-service.yaml
---
apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
kind: Deployment
metadata:
  name: nginx
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: nginx
  replicas: 3 # tells deployment to run 1 pods matching the template
  template: # create pods using pod definition in this template
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
  labels:
    app: nginx
spec:
  externalTrafficPolicy: Local
  ports:
    - name: http
      port: 80
  selector:
    app: nginx
  type: NodePort

$ kubectl create -f https://raw.githubusercontent.com/wx-chevalier/Backend-Boilerplates/master/K8s/Base/nginx-deployment-service.yaml

$ kubectl get pod

NAME                                             READY   STATUS    RESTARTS   AGE
nginx-56db997f77-2q6qz                           1/1     Running   0          3m21s
nginx-56db997f77-fv2zs                           1/1     Running   0          3m21s
nginx-56db997f77-wx2q5                           1/1     Running   0          3m21s

$ kubectl get deployment

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
nginx                           3/3     3            3           3m36s

$ kubectl get svc

NAME                            TYPE           CLUSTER-IP      EXTERNAL-IP                              PORT(S)                      AGE
kubernetes                      ClusterIP      10.43.0.1       <none>                                   443/TCP                      21h
nginx                           NodePort       10.43.8.50      <none>                                   80:32356/TCP                 4m5s

Ingress

Ingress是一种Kubernetes资源，也是将Kubernetes集群内服务暴露到外部的一种方式。ngress只是一个统称，其由Ingress和Ingress Controller两部分组成。Ingress用作将原来需要手动配置的规则抽象成一个Ingress对象，使用YAML格式的文件来创建和管理。Ingress Controller用作通过与Kubernetes API交互，动态的去感知集群中Ingress规则变化。

目前可用的Ingress Controller类型有很多，比如：Nginx、HAProxy、Traefik等，Nginx Ingress使用ConfigMap来管理Nginx配置。

Helm安装Ingress

$ helm install --name nginx-ingress --set "rbac.create=true,controller.service.externalIPs[0]=172.19.157.1,controller.service.externalIPs[1]=172.19.157.2,controller.service.$
xternalIPs[2]=172.19.157.3" stable/nginx-ingress

NAME:   nginx-ingress
LAST DEPLOYED: Tue Aug 20 14:50:13 2019
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/ConfigMap
NAME                      DATA  AGE
nginx-ingress-controller  1     0s

==> v1/Pod(related)
NAME                                            READY  STATUS             RESTARTS  AGE
nginx-ingress-controller-5f874f7bf4-nvsvv       0/1    ContainerCreating  0         0s
nginx-ingress-default-backend-6f598d9c4c-vj4v8  0/1    ContainerCreating  0         0s

==> v1/Service
NAME                           TYPE          CLUSTER-IP    EXTERNAL-IP                             PORT(S)                     AGE
nginx-ingress-controller       LoadBalancer  10.43.115.59  172.19.157.1,172.19.157.2,172.19.157.3  80:32122/TCP,443:32312/TCP  0s
nginx-ingress-default-backend  ClusterIP     10.43.8.65    <none>                                  80/TCP                      0s

==> v1/ServiceAccount
NAME           SECRETS  AGE
nginx-ingress  1        0s

==> v1beta1/ClusterRole
NAME           AGE
nginx-ingress  0s

==> v1beta1/ClusterRoleBinding
NAME           AGE
nginx-ingress  0s

==> v1beta1/Deployment
NAME                           READY  UP-TO-DATE  AVAILABLE  AGE
nginx-ingress-controller       0/1    1           0          0s
nginx-ingress-default-backend  0/1    1           0          0s

==> v1beta1/PodDisruptionBudget
NAME                           MIN AVAILABLE  MAX UNAVAILABLE  ALLOWED DISRUPTIONS  AGE
nginx-ingress-controller       1              N/A              0                    0s
nginx-ingress-default-backend  1              N/A              0                    0s

部署完成后我们可以看到Kubernetes服务中增加了nginx-ingress-controller和nginx-ingress-default-backend两个服务。nginx-ingress-controller为Ingress Controller，主要做为一个七层的负载均衡器来提供HTTP路由、粘性会话、SSL终止、SSL直通、TCP和UDP负载平衡等功能。nginx-ingress-default-backend为默认的后端，当集群外部的请求通过Ingress进入到集群内部时，如果无法负载到相应后端的Service上时，这种未知的请求将会被负载到这个默认的后端上。

$ kubectl get svc
NAME                            TYPE           CLUSTER-IP      EXTERNAL-IP                              PORT(S)                      AGE
kubernetes                      ClusterIP      10.43.0.1       <none>                                   443/TCP                      20h
nginx-ingress-controller        LoadBalancer   10.43.115.59    172.19.157.1,172.19.157.2,172.19.157.3   80:32122/TCP,443:32312/TCP   77m
nginx-ingress-default-backend   ClusterIP      10.43.8.65      <none>                                   80/TCP                       77m

$ kubectl --namespace default get services -o wide -w nginx-ingress-controller

NAME                       TYPE           CLUSTER-IP     EXTERNAL-IP                              PORT(S)                      AGE   SELECTOR
nginx-ingress-controller   LoadBalancer   10.43.115.59   172.19.157.1,172.19.157.2,172.19.157.3   80:32122/TCP,443:32312/TCP   77m   app=nginx-ingress,component=controller,release=nginx-ingress

由于我们采用了externalIP方式对外暴露服务，所以nginx-ingress-controller会在三台节点宿主机上的暴露80/443端口。我们可以在任意节点上进行访问，因为我们还没有在Kubernetes集群中创建Ingress资源，所以直接对ExternalIP的请求被负载到了nginx-ingress-default-backend上。nginx-ingress-default-backend默认提供了两个URL进行访问，其中的/healthz用作健康检查返回200，而/返回404错误。

$ curl 127.0.0.1/
# default backend - 404

$ curl 127.0.0.1/healthz/
# 返回的是 200

后续我们如果需要创建自身的Ingress配置，可以参考如下方式：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
  name: example
  namespace: foo
spec:
  rules:
    - host: www.example.com
      http:
        paths:
          - backend:
              serviceName: exampleService
              servicePort: 80
            path: /
  # This section is only required if TLS is to be enabled for the Ingress
  tls:
    - hosts:
        - www.example.com
      secretName: example-tls

如果希望使用TLS，那么需要创建包含证书与Key的Secret：

apiVersion: v1
kind: Secret
metadata:
  name: example-tls
  namespace: foo
data:
  tls.crt: <base64 encoded cert>
  tls.key: <base64 encoded key>
type: kubernetes.io/tls

WordPress

Helm安装完毕后，我们来测试部署一个WordPress应用：

$ helm install --name wordpress-test --set "ingress.enabled=true,persistence.enabled=false,mariadb.persistence.enabled=false" stable/wordpress

NAME:  wordpress-test
...

这里我们使用Ingress负载均衡进行访问，可以通过如下方式访问到服务：

$ kubectl get ingress

NAME                             HOSTS             ADDRESS                                  PORTS   AGE
wordpress.local-wordpress-test   wordpress.local   172.19.157.1,172.19.157.2,172.19.157.3   80      59m

$ curl -I http://wordpress.local -x 127.0.0.1:80

HTTP/1.1 200 OK
Server: nginx/1.15.6
Date: Tue, 20 Aug 2019 07:55:21 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Powered-By: PHP/7.0.27
Link: <http://wordpress.local/wp-json/>; rel="https://api.w.org/"

也可以根据Charts的说明，利用如下命令获得WordPress站点的管理员用户和密码：

echo Username: user
echo Password: $(kubectl get secret --namespace default wordpress-test-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

==> v1beta1/Role
NAME           AGE
nginx-ingress  0s

==> v1beta1/RoleBinding
NAME           AGE
nginx-ingress  0s

延伸阅读

某熊的技术之路指北 ☯ 就是对笔者不同领域方面沉淀下的知识仓库的导航与索引，便于读者快速地寻找到自己需要的内容。路漫漫其修远兮，吾正上下而求索，也希望能给所有遇见过笔者痕迹的同学些许帮助，在浩瀚银河间能顺利达到一个又一个彼岸。

您还可以前往 NGTE Books 主页浏览包含知识体系、编程语言、软件工程、模式与架构、Web与大前端、服务端开发实践与工程架构、分布式基础架构、人工智能与深度学习、产品运营与创业等多类目的书籍列表：

最近更新于0001-01-01