利用 istio 来对运行在 Kubernetes 上的微服务进行管理

尝试在一个准生产环境下，利用 istio 来对运行在 Kubernetes 上的微服务进行管理。

这一篇是第一篇，将一些主要的坑和环境准备工作。

内容较多，因此无法写成手把手教程，希望读者有一定 Kubernetes 的操作基础。

准备镜像

初始运行需要的镜像包括以下几个：

istio/mixer:0.1.6
pilot:0.1.6
proxy_debug:0.1.6
istio-ca:0.1.6

首先要解决的自然还是镜像的存放问题，官方在源码中提供了很方便的工具，用来根据模板生成在 Kubernetes 中运行 istio 的 YAML 文件：

./updateVersion.sh \

    -p 10.211.55.86:5000/istio,0.1.6 \

    -c 10.211.55.86:5000/istio,0.1.6 \

    -x 10.211.55.86:5000/istio,0.1.6

这一脚本在源码的 install 目录下。

Kubernetes 环境

这里我们使用的集群大概情况是：

1.7.1 版本的 Kubernetes
开启了 RBAC
预备使用的命名空间为：default
PVC 自动供给
无互联网连接
具有自己的私库

启动 istio

RBAC 相关

首先，install 目录中提供的 rbac 文件授权范围不足，所以需要手工编辑istio-rbac-beta.yaml，把其中的几个 RoleBinding，改为 ClusterRoleBinding。

kubectl create \

    -f istio-rbac-beta.yaml

另外缺省的 ClusterRole 中缺乏对 Namespace 的权限，新版本已经修正，目前版本仍需添加：

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

  name: istio-pilot

rules:

- apiGroups: ["istio.io"]

  resources: ["istioconfigs", "istioconfigs.istio.io"]

  verbs: ["*"]

- apiGroups: ["extensions"]

  resources: ["thirdpartyresources", "thirdpartyresources.extensions", "ingresses", "ingresses/status"]

  verbs: ["*"]

- apiGroups: [""]

  resources: ["configmaps", "endpoints", "pods", "services"]

  verbs: ["*"]

- apiGroups: [""]

  resources: ["namespaces", "nodes", "secrets"]

  verbs: ["get", "list", "watch"]

启动 istio 组件

kubectl create \

    -f istio.yaml \

创建 PVC

kind: PersistentVolumeClaim

apiVersion: v1

metadata:

  name: frontend-v1

spec:

  accessModes:

  - ReadWriteOnce

  resources:

    requests:

      storage: 1Gi

准备工作负载

这里我们使用官方的 PHP + Apache 镜像作为工作负载来进行下面的测试，例如我们准备好的 YAML 如下：

Deployment：

kind: Deployment

apiVersion: extensions/v1beta1

metadata:

  name: frontend

  labels:

    name: frontend

    version: "1"

spec:

  replicas: 1

  template:

    metadata:

      labels:

        name: frontend

        version: "1"

    spec:

      containers:

      - name: php

        image: 10.211.55.86:5000/php:7.1.7-apache

        ports:

        - containerPort: 80

          protocol: TCP

        volumeMounts:

        - name: wwwroot

          mountPath: /var/www/html

        env:

        - name: "SERVICE_VERSION"

          value: "1"

        volumes:

      - name: wwwroot

        persistentVolumeClaim:

          claimName: frontend-v1

服务定义：

kind: Service

apiVersion: v1

metadata:

  name: svc-frontend

  labels:

    name: frontend

    version: "1"

spec:

  type: NodePort

  ports:

  - protocol: TCP

    port: 80

    targetPort: 80

    nodePort: 32010

  selector:

    name: frontend

在 Web 目录中我们随便做了个index.php，用来展示当前所在 Pod 和环境变量中的服务版本号，备用。

Tips：一般这类测试，我都懒得重新做一个 Docker 镜像，一般是另外用一个 Pod 挂载同一个 PVC，直接编辑页面文件，或者使用kubectl cp命令进行拷贝。

index.php

<?php

header("Content-type: text/plain");

echo "From: ".gethostname()."\n";

echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

delay.php

<?php

header("Content-type: text/plain");

sleep(4);

echo "\n-----------------------------\n";

echo "\nFrom: ".gethostname()."\n";

echo "Version: ".$_ENV['SERVICE_VERSION']."\n";

运行成功后，访问该服务的 nodePort，会看到相应的输出内容。

istio 的注入

首先用kubectl delete -f删除上文的服务和 Deployment。

上面为了测试方便，给 Service 使用了 NodePort 类型，这里我们去掉这一服务的 NodePort，用 ClusterIP 的形式运行：

spec:

  ports:

  - protocol: TCP

    port: 80

    targetPort: 80

  selector:

    name: frontend

接下来进行注入操作

istioctl kube-inject -f frontend-v1.yaml > frontend-v1-istio.yaml

观察注入操作会发现，其中多了一个 Sidecar Container（下面的 Image 节内容已经被我修改为本地私库）：

    env:

    - name: POD_NAME

      valueFrom:

        fieldRef:

          fieldPath: metadata.name

    - name: POD_NAMESPACE

      valueFrom:

        fieldRef:

          fieldPath: metadata.namespace

    - name: POD_IP

      valueFrom:

        fieldRef:

          fieldPath: status.podIP

    image: 10.211.55.86:5000/istio/proxy_debug:0.1.6

    imagePullPolicy: Always

    name: proxy

    resources: {}

    securityContext:

      runAsUser: 1337

另外还在pod.beta.kubernetes.io/init-containers注解中进行了初始化：

[{

  "args": ["-p", "15001", "-u", "1337"],

  "image": "10.211.55.86:5000/istio/init:0.1",

  "imagePullPolicy": "Always",

  "name": "init",

  "securityContext": {

    "capabilities": {

      "add": ["NET_ADMIN"]

    }

  }

}, {

  "args": ["-c", "sysctl -w kernel.core_pattern=/tmp/core.%e.%p.%t \u0026\u0026 ulimit -c unlimited"],

  "command": ["/bin/sh"],

  "image": "10.211.55.86:5000/alpine",

  "imagePullPolicy": "Always",

  "name": "enable-core-dump",

  "securityContext": {

    "privileged": true

  }

}]

可以看到上面一共涉及三个镜像：

docker.io/istio/proxy_debug:0.1
docker.io/istio/init:0.1
alpine

经过一番折腾：

原有 YAML
注入，生成新的 YAML
替换新 YAML 中的镜像地址

就把原有的容器应用封装成新的 istio 支持的微服务了。

准备测试素材

另外我们需要准备一个工具服务，用于在 shell 中进行测试：

kind: Deployment

apiVersion: extensions/v1beta1

metadata:

  name: tool

  labels:

    name: tool

    version: "1"

spec:

  replicas: 1

  template:

    metadata:

      labels:

        name: tool

        version: "1"

    spec:

      containers:

      - name: tool

        image: 10.211.55.86:5000/php:7.1.7-apache

        ports:

        - containerPort: 80

          protocol: TCP

        volumeMounts:

        - name: wwwroot

          mountPath: /var/www/html

      volumes:

      - name: wwwroot

        persistentVolumeClaim:

          claimName: frontend-v1

---

kind: Service

apiVersion: v1

metadata:

  name: tool

  labels:

    name: tool

spec:

  ports:

  - protocol: TCP

    port: 80

    targetPort: 80

  selector:

    name: tool

同样的，这里也需要执行istioctl kube-inject进行注入，运行之后，就得到一个运行于集群内部的 Linux Shell，istio 中的路由策略经常是客户端和服务器协同完成的，因此上客户和服务器的 Deployment 都需要进行注入操作。

K8S中文文档 docs.kubernetes.org.cn

转自：https://www.kubernetes.org.cn/2449.html

秒客网