1、前言
在本章节中,我们将学习一些监控(Prometheus)、追踪(Zipkin)、数据可视化工具(Grafana)和服务拓扑结构(Kiali)。(我们又学到了一款Zipkin的链路追踪组件,为什么没有用Skywalking呢?主要还是Istio原生未做支持)
为了让 Grafana 和 Kiali 工作,我们首先要安装 Prometheus 插件。
安装Prometheus, Grafana, Zipkin, Kiali 的前提是已经安装好了istio。
2、可观察性
上节课我们使用 sidecar 部署了应用,即 Envoy 代理会运行在应用实例旁边并拦截流量,同时这些代理还有一个功能就是:收集指标。
Envoy 代理收集的指标可以帮助我们获得系统状态的可见性。获得系统的这种可见性是至关重要的,因为我们需要了解正在发生的事情,并授权运维人员对应用程序进行故障排除、维护和优化。
Istio 生成三种类型的遥测数据,为网格中的服务提供可观察性:
- 指标度量(Metric)
- 分布式追踪
- 访问日志
3、指标
Istio 基于四个黄金信号生成指标:延迟、流量、错误和饱和度。
- 延迟:表示服务一个请求所需的时间。这个指标应该分成成功请求(如 HTTP 200)和失败请求(如 HTTP 500)的延迟。
- 流量:是衡量对系统的需求有多大,它是以系统的具体指标来衡量的。例如,每秒的 HTTP 请求,或并发会话,每秒的检索量,等等。
- 错误:用来衡量请求失败的比率(例如 HTTP 500)。
- 饱和度:衡量一个服务中最紧张的资源有多满。例如,线程池的利用率。
这些指标是在不同的层面上收集的,首先是最细的,即 Envoy 代理层面,然后是服务层面和控制平面的指标。
1、代理级指标
生成指标的关键角色是 Envoy,它生成了一套关于所有通过代理流量的丰富指标。使用Envoy 生成的指标,我们可以以最低的粒度来监控服务网格,例如 Envoy 代理中的每个监听器和集群的指标。
作为运维人员,我们也要有能力控制生成和收集工作负载实例中的哪些 Envoy 指标。
下面是几个代理级指标的例子。
envoy_cluster_internal_upstream_rq{response_code_class="2xx",cluster_name="xds-grpc"} 7163
envoy_cluster_upstream_rq_completed{cluster_name="xds-grpc"} 7164
envoy_cluster_ssl_connection_error{cluster_name="xds-grpc"} 0
envoy_cluster_lb_subsets_removed{cluster_name="xds-grpc"} 0
envoy_cluster_internal_upstream_rq{response_code="503",cluster_name="xds-grpc"} 1
注意你可以从每个 Envoy 代理实例的
/stats
端点查看代理级指标。
2、服务级指标
服务级别的指标涵盖了我们前面提到的四个黄金信号。这些指标使我们 能够监控服务与服务之间的通信。此外,Istio 还提供了一组仪表盘,我们可以根据这些指标来监控服务行为。
就像代理级别的指标一样,运维人员可以自定义收集哪些服务级别的指标。
默认情况下,Istio 的标准指标集会被导出到 Prometheus。
下面是几个服务级指标的例子:
istio_requests_total{
connection_security_policy="mutual_tls",
destination_app="hello-world",
destination_canonical_service="hello-world",
destination_canonical_revision="v1",
destination_principal="cluster.local/ns/default/sa/default",
destination_service="hello-world.default.svc.cluster.local",
destination_service_name="hello-world",
destination_service_namespace="default",
destination_version="v1",
destination_workload="hello-world-v1",
destination_workload_namespace="default",
reporter="destination",
request_protocol="http",
response_code="200",
response_flags="-",
source_app="hello-web",
source_canonical_service="hello-web",
source_canonical_revision="v1",
source_principal="cluster.local/ns/default/sa/default",
source_version="v1",
source_workload="hello-web-v1",
source_workload_namespace="default"
} 981
3、控制平面度量
Istio 也会生成控制平面指标,用于监控 Istio 的控制平面,而不是用户服务。
输出的控制平面指标的完整列表可以在 这里 找到。
控制平面指标包括冲突的入站/出站监听器的数量、没有实例的集群数量、被拒绝或被忽略的配置等指标。
4、Prometheus
1、安装prometheus
Prometheus 是一个开源的监控系统和时间序列数据库。Istio 使用 Prometheus 来记录指标,跟踪 Istio 和网格中的应用程序的健康状况。
要安装 Prometheus,我们可以使用 Istio 安装包中/samples/addons
文件夹中的示例安装。
$ cd istio-1.20.1/
$ ls
bin LICENSE manifests manifest.yaml README.md samples tools
$ cd samples/ && ls
addons bookinfo certs cicd custom-bootstrap extauthz external grpc-echo health-check helloworld httpbin jwt-server kind-lb multicluster open-telemetry operator ratelimit README.md security sleep tcp-echo wasm_modules websockets
$ cd addons/ && ls
#prometheus.yaml是安装prometheus的yaml文件
extras grafana.yaml jaeger.yaml kiali.yaml loki.yaml prometheus.yaml README.md
#可以看到安装prometheus需要用到两个镜像:jimmidyson/configmapreload:v0.5.0和prom/prometheus:v2.31.1
$ grep image prometheus.yaml
image: "jimmidyson/configmap-reload:v0.8.0"
imagePullPolicy: "IfNotPresent"
image: "prom/prometheus:v2.41.0"
imagePullPolicy: "IfNotPresent"
#安装prometheus
$ kubectl apply -f prometheus.yaml
serviceaccount/prometheus created
configmap/prometheus created
clusterrole.rbac.authorization.k8s.io/prometheus created
clusterrolebinding.rbac.authorization.k8s.io/prometheus created
service/prometheus created
deployment.apps/prometheus created
$ kubectl get deploy -n istio-system
NAME READY UP-TO-DATE AVAILABLE AGE
istio-egressgateway 1/1 1 1 26h
istio-ingressgateway 1/1 1 1 26h
istiod 1/1 1 1 26h
prometheus 1/1 1 1 30s
#验证
$ kubectl get pod -n istio-system -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
istio-egressgateway-765d784c5-5q5ch 1/1 Running 0 153m 10.18.241.93 master01 <none> <none>
istio-ingressgateway-869d777659-hbmq9 1/1 Running 0 153m 10.18.241.105 master01 <none> <none>
istiod-5c4f4498d-5bkpg 1/1 Running 0 153m 10.18.235.23 master03 <none> <none>
prometheus-5d5d6d6fc-cgzrm 2/2 Running 0 43s 10.18.186.197 node03 <none> <none>
临时使用ingress进行服务的暴露
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: istio-system
name: prometheus-ingress
spec:
ingressClassName: nginx
rules:
- host: prometheus-istio.kubernets.cn
http:
paths:
- pathType: Prefix
backend:
service:
name: prometheus
port:
number: 9090
path: /
验证:

2 部署示例应用
为了看到一些请求和流量,我们将部署一个 Nginx 实例:
$ kubectl create deployment nginx --image=hub.c.163.com/library/nginx:latest -n microservice
为了能够产生一些流量并访问 Nginx Pod,我们需要以某种方式让它可以被访问。
最简单的方法是将 Nginx 部署作为 Kubernetes NodePort服务公开:<以后可以使用Istio 资源并通过 Istio 的入口网关暴露服务>
$ kubectl expose deployment nginx --type=NodePort --name=nginxsvc --port=80 -n microservice
现在我们可以运行 kubectl get services ,查看 nginxsvc 服务:
$ kubectl get service -n microservice
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginxsvc NodePort 10.15.215.87 <none> 80:32101/TCP 23s
这时只要访问任意node的 IP:31366,就可以访问Nginx服务。
$ curl 192.10.192.158:32101
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
Prometheus 验证数据
输入istio_requests_total
之后,点击Execute执行,就可以看到收集到的数据早先有小伙伴问我的一个问题,如何基于应用层面的 request
指标数据做弹性的扩缩容,那么下面这个指标是不是就可以用起来了?

5、Grafana
1、安装Grafana
Grafana是一个用于分析和监控的开放平台。Grafana 可以连接到各种数据源,并使用图形、表格、热图等将数据可视化。
通过强大的查询语言,你可以定制现有的仪表盘并创建更高级的可视化。
通过 Grafana,我们可以监控 Istio 安装和服务网格中运行的应用程序的健康状况。
我们可以使用grafana.yaml
来部署带有预配置仪表盘的 Grafana 示例安装。该 YAML文件在 Istio 安装包的/samples/addons
下。
确保在部署 Grafana 之前部署 Promeheus 插件,因为 Grafana 使用 Prometheus作为其数据源。
运行下面的命令来部署 Grafana 和预配置的仪表盘:
$ kaf grafana.yaml
serviceaccount/grafana created
configmap/grafana created
service/grafana created
deployment.apps/grafana created
configmap/istio-grafana-dashboards created
configmap/istio-services-grafana-dashboards created
$ kubectl get pod -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-5f9b8c6c5d-8lwwb 1/1 Running 0 42s
istio-egressgateway-765d784c5-5q5ch 1/1 Running 0 160m
istio-ingressgateway-869d777659-hbmq9 1/1 Running 0 160m
istiod-5c4f4498d-5bkpg 1/1 Running 0 160m
prometheus-5d5d6d6fc-cgzrm 2/2 Running 0 7m9s
临时再次通过ingress将服务暴露:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: istio-system
name: grafana-ingress
spec:
ingressClassName: nginx
rules:
- host: grafana-istio.kubernets.cn
http:
paths:
- pathType: Prefix
backend:
service:
name: grafana
port:
number: 3000
path: /
验证:
$ kgi -nistio-system
NAME CLASS HOSTS ADDRESS PORTS AGE
grafana-ingress nginx grafana-istio.zhoumx.cc 10.0.10.5 80 46s
访问验证:
点击搜索框和 istio 文件夹,查看已安装的仪表盘,如下图所示。

Istio Grafana 安装时预配置了以下仪表盘:
Istio 控制平面仪表盘(Istio Control Plane Dashboard)
Istio Control Plane Dashboard 仪表盘将向我们展示 Istio 控制平面的健康和性能。控制平面的资源使用情况(内存、CPU、磁盘、Go routines),以及关于 Pilot、Envoy和 Webhook 的信息。

Istio 网格仪表盘(Istio Mesh Dashboard)
网格仪表盘为我们提供了在网格中运行的所有服务的概览。仪表盘包括全局请求量、成功率以及 4xx 和 5xx 响应的数量。
Istio 性能仪表盘(Istio Performance Dashboard)
性能仪表盘向我们展示了 Istio 主要组件在稳定负载下的资源利用率。

Istio 服务仪表盘(Istio Service Dashboard)
服务仪表盘允许我们在网格中查看服务的细节。
我们可以获得关于请求量、成功率、持续时间的信息,以及显示按来源和响应代码、持续时间和大小的传入请求的详细图表。

Istio Wasm 扩展仪表盘(Istio Wasm Extension Dashboard)
Istio Wasm 扩展仪表盘显示与 WebAssembly 模块有关的指标。从这个仪表盘,我们可以监控活动的和创建的 Wasm 虚拟机,关于获取删除 Wasm 模块和代理资源使用的数据。
Istio 工作负载仪表盘(Istio Workload Dashboard)
这个仪表盘为我们提供了一个工作负载的详细指标分类。

6、Zipkin 分布式追踪
Zipkin 是一个分布式追踪系统。我们可以 轻松地监控服务网格中发生的分布式事务,发现任何性能或延迟问题。
为了让我们的服务参与分布式追踪,我们需要在进行任何下游服务调用时传播服务的HTTP 头信息。尽管所有的请求都要经过 Istio sidecar,但 Istio 没有办法将出站请求与产生这些请求的入站请求联系起来。通过在应用程序中传播相关的头信息可以帮助Zipkin 将这些跟踪信息拼接起来。
Istio 依赖于 B3 跟踪头(以x-b3
开头的 header)和 Envoy 生成的请求 ID(xrequest-id
)。B3 头信息用于跨服务边界的跟踪上下文传播。
以下是我们需要在我们的应用程序中对每个发出的请求进行传播的特定头文件名称:
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
b3
如果你使用 Lightstep,你还需要转发名为
x-ot-span-context
的头。
传播头信息最常见的方法是从传入的请求中复制它们,并将它们包含在所有从你的应用程序发出的请求中。
你用 Istio 服务网格得到的跟踪只在服务边界捕获。为了了解应用程序的行为并排除故障,你需要通过创建额外的跨度(span)来正确检测你的应用程序。
要安装 Zipkin,我们可以使用 addons 文件夹中的zipkin.yaml
文件。
$ pwd
istio-1.20.1/samples/addons/extras
$ ls
prometheus-operator.yaml prometheus_vm_tls.yaml prometheus_vm.yaml
zipkin.yaml
$ kubectl apply -f zipkin.yaml
deployment.apps/zipkin created
service/tracing created
service/zipkin created
#所需的镜像为openzipkin/zipkin-slim:2.23.14
$ grep image zipkin.yaml
image: openzipkin/zipkin-slim:2.23.14
#可以看到zipkin运行起来了
$ kubectl get pod -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-5f9b8c6c5d-8lwwb 1/1 Running 0 6m30s
istio-egressgateway-765d784c5-5q5ch 1/1 Running 0 166m
istio-ingressgateway-869d777659-hbmq9 1/1 Running 0 166m
istiod-5c4f4498d-5bkpg 1/1 Running 0 166m
prometheus-5d5d6d6fc-cgzrm 2/2 Running 0 12m
zipkin-7d7cd94c9b-6ssjg 1/1 Running 0 27s
继续临时再次通过ingress将服务暴露:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: istio-system
name: zipkin-ingress
spec:
ingressClassName: nginx
rules:
- host: zipkin-istio.kubernets.cn
http:
paths:
- pathType: Prefix
backend:
service:
name: zipkin
port:
number: 9411
path: /
验证:
$ kgi -nistio-system
NAME CLASS HOSTS ADDRESS PORTS AGE
zipkin-ingress nginx zipkin-istio.zhoumx.cc 10.0.10.5 80 6s
访问验证:

7、Kiali
Kiali 的 Graph 数据主要来自两个来源:Prometheus 和 Istio 本身的遥测数据。
Prometheus:Prometheus 是一个开源监控和警报工具,它用于收集和存储 Istio 服务网格中的指标数据。Istio 使用 Envoy 代理收集遥测数据,这些数据随后被 Prometheus抓取和存储。Kiali 使用这些 Prometheus 数据来生成服务之间的流量、错误率、延迟等指标。
Istio 遥测数据:Istio 服务网格生成的遥测数据包括请求、响应、延迟以及 Envoy 代理的其他性能指标。这些数据由 Istio 组件(例如 Mixer 和 Pilot)以及 Envoy 代理本身生成。Kiali 从这些遥测数据中获取服务拓扑信息,以创建服务之间的依赖关系图。
Kiali 将这两个数据源的信息整合在一起,生成 Graph,它展示了服务网格的拓扑结构、服务之间的流量以及其他性能指标。这有助于用户更好地理解服务之间的依赖关系,发现潜在的性能问题,并优化服务网格配置。
要安装 Kiali,请使用 addons 文件夹中的 kiali.yaml 文件:
$ cd istio-1.14.3/samples/addons/
$ ls
extras grafana.yaml jaeger.yaml kiali.yaml prometheus.yaml README.md
#所需镜像为quay.io/kiali/kiali:v1.76
$ grep image kiali.yaml
image_digest: ""
image_name: quay.io/kiali/kiali
image_pull_policy: Always
image_pull_secrets: []
image_version: v1.76
- image: "quay.io/kiali/kiali:v1.76"
imagePullPolicy: Always
#创建kiali
$ kubectl apply -f kiali.yaml
serviceaccount/kiali created
configmap/kiali created
clusterrole.rbac.authorization.k8s.io/kiali-viewer created
clusterrole.rbac.authorization.k8s.io/kiali created
clusterrolebinding.rbac.authorization.k8s.io/kiali created
role.rbac.authorization.k8s.io/kiali-controlplane created
rolebinding.rbac.authorization.k8s.io/kiali-controlplane created
service/kiali created
deployment.apps/kiali created
$ kubectl get pod -n istio-system
NAME READY STATUS RESTARTS AGE
grafana-5f9b8c6c5d-8lwwb 1/1 Running 0 9m50s
istio-egressgateway-765d784c5-5q5ch 1/1 Running 0 169m
istio-ingressgateway-869d777659-hbmq9 1/1 Running 0 169m
istiod-5c4f4498d-5bkpg 1/1 Running 0 169m
kiali-cc67f8648-dw98r 1/1 Running 0 48s
prometheus-5d5d6d6fc-cgzrm 2/2 Running 0 16m
zipkin-7d7cd94c9b-6ssjg 1/1 Running 0 3m47s
注意,如果你看到任何错误,例如在版本monitoringkiali.io/v1alpha
中没有匹配的MonitoringDashboard
,请重新运行kubectl apply
命令。问题是,在安装 CRD(自定义资源定义)和由该 CRD 定义的资源时,可能存在一个匹配条件。
继续临时再次通过ingress将服务暴露:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
namespace: istio-system
name: kiali-ingress
spec:
ingressClassName: nginx
rules:
- host: kiali-istio.kubernets.cn
http:
paths:
- pathType: Prefix
backend:
service:
name: kiali
port:
number: 20001
path: /
验证:
$ kgi -nistio-system
NAME CLASS HOSTS ADDRESS PORTS AGE
grafana-ingress nginx grafana-istio.zhoumx.cc 10.0.10.5 80 8m42s
kiali-ingress nginx kiali-istio.zhoumx.cc 10.0.10.5 80 19s
prometheus-ingress nginx prometheus-istio.zhoumx.cc 10.0.10.5 80 14m
zipkin-ingress nginx zipkin-istio.zhoumx.cc 10.0.10.5 80 3m1s
访问验证:

Kiali 提供创建、更新和删除 Istio 配置的操作,由向导驱动。我们可以配置请求路由、故障注入、流量转移和请求超时,所有这些都来自用户界面。如果我们有任何现有的Istio 配置已经部署,Kiali 可以验证它并报告任何警告或错误。