本文记录了作者在Azure Kubernetes集群上安装istio的过程，以及对应用示例的操作。
除非你是与世隔绝，否则你可能已经知道微服务架构模式在过去几年中迅速普及。这是由两方面来推动的，一方面是云部署服务越来越便利，另一方面是小团队首先期望专注于构建简单好用的子服务，然后才是构建应用程序。
总的来说，这样很好，但也导致了其他一些问题：
1、增加了API层面的安全问题。使用较小的服务，以及服务之间的许多依赖关系，必须有更多的端点以确保安全。复合(Compounding)是一种 “不信任”（“trust nothing”）安全模型的举措，包括内部网络，因此devops团队需要建立一种机制来验证正在与我交流的微服务是真实的。
2、需要监控更多的服务。监控是必须的，但是微服务架构模型又需要添加另一层监控。例如，当发现一个性能问题时，您现在不能判断是服务应用还是后端存储的问题。也可能，是由它所使用的任何依赖服务引起的。对服务延迟进行简单的监控是不够的，您还需要对服务使用的每个依赖关系进行度量。
3、流量管理问题。在多个团队不断发展的服务之间的互连的数量，意味着我们需要以多种方式管理它们之间的流量：在应用程序的不同版本之间切换流量、速率限制、回路阻断等，以防止依赖服务的级联故障。
Istio是CNCF赞助的一个项目，旨在解决这些问题。这篇博客文章将帮助您安装Istio，并演示如何对示例应用程序进行操作。
我将使用Azure做演示，但在本教程中所需的全部内容是RBAC启用的Kubernetes 1.9集群和MutatingAdmissionWebhook Admission Controller插件。如果您使用其他的云创建您的群集，可以跳过下一节。
Azure Kubernetes集群创建记录
对于ACS引擎（ACS Engine）的当前缺省值，必须重写默认的包含MutatingAdmissionWebhook的Admission Controllers插件，以便以后可以自动为服务注入sidecar容器。您可以在ACS引擎cluster.json中通过指定实现（参考Kubernetes1.9项目的部署建议）：
{
"apiVersion": "vlabs",
"properties": {
"orchestratorProfile": {
"orchestratorType": "Kubernetes",
"orchestratorRelease": "1.9",
"kubernetesConfig": {
"apiServerConfig": {
"--admission-control": "NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota"
}
}
},
....
}
在Kubernetes集群上安装Istio
假设已有一个配置了RBAC的Kubernetes1.9集群。首先，获取最新版本的Istio，并添加其CLI工具istioctl到安装目录，可以参照网站上 安装步骤 的前四个步骤执行。
在写这篇文章时，helm chart还不能正常工作，所以不要走这条路。而是将项目解压后，用kubectl apply安装到项目的根目录：
$ kubectl apply -f install/kubernetes/istio-auth.yaml
你能看到istio的核心组件启动起来，最后得到一组pod，如下：
$ kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
istio-ca-797dfb66c5-5dc6f 1/1 Running 0 2h
istio-ingress-84f75844c4-g666n 1/1 Running 0 2h
istio-mixer-9bf85fc68-l54vm 3/3 Running 0 2h
istio-pilot-575679c565-rkm82 2/2 Running 0 2h
安装自动的sidecar 注入
Istio的核心功能之一是代理服务间的所有流量。这使得它能够做非常有用的事情，比如端点之间的相互认证，在服务的当前/下一版本之间进行业务拆分，并度量请求的等待时间。
Istio在每一个服务pod中创建一个sidecar容器，通过拦截pod创建及执行这种注入来代理流量。
在 Istio项目页面上记录了如何自动注入。为了简洁，下面是用Istio root执行的一组命令来配置这个。首先为Kubernetes CA创建一组证书：
$ ./install/kubernetes/webhook-create-signed-cert.sh \
--service istio-sidecar-injector \
--namespace istio-system \
--secret sidecar-injector-certs
接下来，安装sidecar注入配置图：
$ kubectl apply -f install/kubernetes/istio-sidecar-injector-configmap-release.yaml
然后，建立caBundle YAML文件，用于Kubernetes API服务器调用WebHook：
$ cat install/kubernetes/istio-sidecar-injector.yaml | \
./install/kubernetes/webhook-patch-ca-bundle.sh> \
install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml
最后，安装sidecar injector webhook。
$ kubectl apply -f install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml
sidecar injector webhook现在可以运行了：
$ kubectl -n istio-system get deployment -listio=sidecar-injector
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE istio-sidecar-injector 1 1 1 1 1d
安装已绑定的工具
默认情况下，Istio不会将其sidecar代理注入到应用程序pod中，而是需要引导它对特定的命名空间注入sidecar。现在我们为默认命名空间执行以下操作：
$ kubectl label namespace default istio-injection**=**enabled
Istio包括一个叫做BookInfo的应用程序示例，我们可以使用它来观察这种注入，以及Istio的其他功能。可以通过上面的链接了解这个应用程序的体系结构，然后安装它：
$ kubectl apply -f samples/bookinfo/kube/bookinfo.yaml
一旦创建了pod，你会发现它们不是通常的1/1，而是2/2：
$kubectl get pods
NAME READY STATUS RESTARTS AGE
details-v1-64b86cd49-8tn9p 2/2 Running 0 15s
productpage-v1-84f77f8747-6dh6l 2/2 Running 0 13s
ratings-v1-5f46655b57-bpwkb 2/2 Running 0 14s
reviews-v1-ff6bdb95b-m8f6f 2/2 Running 0 14s
reviews-v2-5799558d68-8t7h8 2/2 Running 0 14s
reviews-v3-58ff7d665b-2hfx2 2/2 Running 0 13s
这表明Istio已经将一个sidecar容器注入到它们中的每一个，它们将对我们前面提到的流量进行代理。执行describe可以查看一个pod的描述（你的pod id可能有所不同）：
$ kubectl describe pod reviews-v1-ff6bdb95b-m8f6f
输出包括两个容器，reviews容器和istio-proxy容器。
可以通过查找Istio的入口控制器的公共IP来查看该应用程序的运行情况：
$ kubectl get services -n istio-system | grep istio-ingress
istio-ingress LoadBalancer 10.0.58.79 13.68.135.154 80:32552/TCP,443:31324/TCP 3h
打开http://13.68.135.154/productpage（需要换成自己的ip）并刷新，会发现有三个版本的应用程序（没有星、红星和黑星）正在负载均衡。
Istio可视化工具
Istio还捆绑了一些非常有用的工具，用于服务网格的管理、调试和可视化。其中第一个是Grafana和Prometheus，它们是用Istio仪表板预先配置的。
在0.5.1版本中，在yaml定义中有一个Prometheus命名空间的bug。编辑install/kubernetes/addons/prometheus.yaml，查找ServiceAccount。确保它的定义开始部分如下，如果缺少命名空间就加上它（这在主机中是固定的。该问题在最近的版本中已被解决，所以如果它看起来像下面的话就可以忽略）
apiVersion: v1
kind: ServiceAccount
metadata:
name: prometheus
namespace: istio-system
这样，您就可以安装所有这些工具了：
$ kubectl apply -f install/kubernetes/addons/prometheus.yaml
$ kubectl apply -f install/kubernetes/addons/grafana.yaml
$ kubectl apply -f install/kubernetes/addons/servicegraph.yaml
$ kubectl apply -f install/kubernetes/addons/zipkin.yaml
一旦启动起来，就应该让这些pod在集群中运行：
$kubectl get pods -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-648859cf87-gpjmw 1/1 Running 0 2h
istio-ca-797dfb66c5-5dc6f 1/1 Running 0 3h
istio-ingress-84f75844c4-g666n 1/1 Running 0 3h
istio-mixer-9bf85fc68-l54vm 3/3 Running 0 3h
istio-pilot-575679c565-rkm82 2/2 Running 0 3h
istio-sidecar-injector-7b559f7f6f-btzr9 1/1 Running 0 2h
prometheus-cf8456855-f2q2r 1/1 Running 0 2h
servicegraph-7ff6c499cc-wm7r2 1/1 Running 0 2h
zipkin-7988c559b7-hsw7x 1/1 Running 0 2h
然后，我们可以通过端口的port-forward命令连接到Grafana前端：
$ exportGRAFANAPOD=$(kubectl get pods -n istio-system | grep "grafana" | awk '{print $1}')
$ kubectl port-forward $GRAFANAPOD -n istio-system 3000:3000
通过浏览器打开http://localhost:3000。
Grafana预先配置了多个仪表板，下面这个用来监视Mixer，Istio的组件之一。
如果您最近点击了图书信息应用程序，您会在输入请求图中看到您的请求。还可以通过可视化看到应用程序的服务如何使用Service Graph进行通信。
$ export SERVICEGRAPHPOD=$(kubectl get pods -n istio-system | grep "servicegraph" | awk '{print $1}')
$ kubectl port-forward $SERVICEGRAPHPOD -n istio-system 8088:8088
在点击多个图书信息页面后，打开http://localhost:8088/dotviz可以看到服务之间的所有互连：
您还可以使用Zipkin查看延迟分解图：
$ export ZIPKINPOD=$(kubectl get pods -n istio-system | grep "zipkin" | awk '{print $1}')
$ kubectl port-forward $ZIPKINPOD -n istio-system 9411:9411
打开http://localhost:9411，您可以点击一个产品页面请求，看看哪些服务组件导致整个延迟：
有关这些工具的详细信息可以参考Istio项目文档https://istio.io/docs/tasks/telemetry/。
Istio流量管理工具
Istio工具的核心在于其流量管理功能。请参照链接，这些文档能够非常清楚地描述如何使用这些工具，并通过这些工具来管理集群中服务之间的通信来解决诸如回路阻断、请求路由、入口和错误注入等。
希望这个演练很有用。如果你有任何反馈或者喜欢这样的内容，请在Twitter上联系或关注我。
原文链接