尝试在一个准生产环境下，利用 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 如下：
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