本文记录了作者在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的组件之一。
图1如果您最近点击了图书信息应用程序,您会在输入请求图中看到您的请求。还可以通过可视化看到应用程序的服务如何使用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可以看到服务之间的所有互连:
图2您还可以使用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,您可以点击一个产品页面请求,看看哪些服务组件导致整个延迟:
图3有关这些工具的详细信息可以参考Istio项目文档https://istio.io/docs/tasks/telemetry/。
Istio流量管理工具
Istio工具的核心在于其流量管理功能。请参照链接,这些文档能够非常清楚地描述如何使用这些工具,并通过这些工具来管理集群中服务之间的通信来解决诸如回路阻断、请求路由、入口和错误注入等。
希望这个演练很有用。如果你有任何反馈或者喜欢这样的内容,请在Twitter上联系或关注我。
网友评论