# istio 三日谈之一，环境准备

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

```bash
./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。

```plaintext
kubectl create \
	-f istio-rbac-beta.yaml
```

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

```yaml
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 组件

```plaintext
kubectl create \
	-f istio.yaml \
```

### 创建 PVC

```yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: frontend-v1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
```

## 准备工作负载

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

Deployment：

```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
```

服务定义：

```yaml
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
<?php
header("Content-type: text/plain");
echo "From: ".gethostname()."\n";
echo "Version: ".$_ENV['SERVICE_VERSION']."\n";
```

### delay.php

```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 的形式运行：

```yaml
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  selector:
    name: frontend
```

接下来进行注入操作

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

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

```yaml
    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`注解中进行了初始化：

```json
[{
  "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 && 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
    

经过一番折腾：

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

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

## 准备测试素材

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

```yaml
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 都需要进行注入操作**。