Istio 核心组件的作用了解

Proxy[Envoy]:

  Proxy在Istio架构中必须要有,Envoy是由Lyft开发并开源,使用C++编写的高性能代理,负责在服务网格中服务的进出流量。Istio使用Envoy代理的扩展版本。Envoy是用c++开发的高性能代理,用于协调服务网格中所有服务的所有入站和出站流量。Envoy代理是唯一与数据平面通信交互的Istio组件。Envoy代理被部署为服务的sidecars,在逻辑上增加了Envoy的许多内置特性,例如:

  • 动态服务发现
  • 负载平衡
  • TLS终止
  • HTTP/2和gRPC代理
  • 断路器
  • 健康检查
  • 分阶段推出基于%的流量分割
  • 故障注入
  • 丰富的指标

  为什么选择Envoy?

  对于Sidecar/Proxy其实不仅仅可以选择Envoy,还可以用Linkerd、Nginx和NginMesh等。像Nginx作为分布式架构中比较广泛使用的网关,Istio默认却没有选择,是因为Nginx没有Envoy优秀的配置扩展,Envoy可以实时配置。

Mixer :

  Mixer在Istio架构中不是必须的,Mixer是一个独立于平台的组件。Mixer跨服务网格执行访问控制和使用策略,并从特使代理和其他服务收集遥测数据。代理提取请求级属性,并将它们发送到Mixer进行评估。Mixer包括一个灵活的插件模型。该模型使Istio能够与各种主机环境和基础设施后端进行交互。因此,Istio从这些细节中抽象出Envoy代理和Istio管理的服务。

  • 为集群执行访问控制,哪些用户可以访问哪些服务,包括白名单检查、ACL检查等
  • 策略管理,比如某个服务最多只能接收多少流量请求
  • 遥测报告上报,比如从Envoy中收集数据[请求数据、使用时间、使用的协议等],通过Adpater上报给Promethues、Heapster等

Pilot:

  Pilot在Istio架构中必须要有,Pilot为 Envoy sidecars 提供服务发现、用于智能路由的流量管理功能(例如,A/B测试、canary滚动等)和弹性(超时、重试、断路器等)。Pilot将控制流量行为的高级路由规则转换为特定于环境的配置,并在运行时将它们传播到sidecars。Pilot将特定于平台的服务发现机制抽象出来,并将它们合成为任何符合Envoy API的sidecar都可以使用的标准格式。下图显示了平台适配器和特使代理如何交互。

 

Galley:

  Galley在Istio架构中不是必须的,主要负责istio配置的校验、各种配置之间统筹,为istio提供配置管理服务。通过kubernetes的webhook机制对pilot和mixer的配置进行验证。

Citadel:

  Citadel在Istio架构中不是必须的,Citadel支持强大的服务对服务和终端用户身份验证,内置身份和凭证管理。您可以使用Citadel来升级服务网格中的未加密流量。使用Citadel,运营商可以执行基于服务身份的策略,而不是相对不稳定的第3层或第4层网络标识。从0.5版开始,您可以使用Istio的授权特性来控制谁可以访问您的服务。在有一些场景中,对于安全要求是非常高的,比如支付,所以Citadel就是用来保证安全的。

Istio 官方Demo  Bookinfo:

  官网:https://istio.io/docs/examples/bookinfo/

  该应用程序由四个单独的微服务组成,用于演示各种Istio功能。该应用程序显示有关书籍的信息,类似于在线书籍商店的单个目录条目。页面上显示的是书的说明,书的详细信息(ISBN,页数等)和一些书评。Bookinfo应用程序分为四个单独的微服务:

  • productpage。该productpage微服务调用detailsreviews微服务来填充页面。
  • details。该details微服务包含图书信息。
  • reviews。该reviews微服务包含了书评。它还称为ratings微服务。
  • ratings。该ratings微服务包含预定伴随书评排名信息。

  reviews微服务有3个版本:

  • 版本v1不会调用该ratings服务。
  • 版本v2调用该ratings服务,并将每个等级显示为1到5个黑星。
  • 版本v3调用该ratings服务,并将每个等级显示为1到5个红色星号。

  该应用程序的端到端体系结构如下所示。

  该应用程序是多语言的,即微服务以不同的语言编写。值得注意的是,这些服务不依赖于Istio,而是提供了一个有趣的服务网格示例,特别是由于服务的多样性,服务的语言和版本reviews。要使用Istio运行示例,无需更改应用程序本身。相反,您只需要在启用Istio的环境中配置和运行服务,并在每个服务旁边注入Envoy辅助工具。最终的部署将如下所示:

  所有微服务都将与Envoy sidecar 打包在一起,该Envoy sidecar 拦截对服务的呼入和呼出,并通过Istio控制平面,路由,遥测收集和整个应用程序的策略实施提供外部控制所需的钩子。

Sidecar自动注入到微服务:

  官网 :https://istio.io/docs/examples/bookinfo/#start-the-application-services

1.默认的Istio安装使用自动sidecar注入。标签的名称空间,它将在启用 istio-injection=enabeld的情况下托管应用程序

  kubectl label namespace default istio-injection=enabled
  kubectl get namespaces --show-labels

2.查看所需镜像,并且下载,所有节点

  下载镜像:

docker pull    istio/examples-bookinfo-details-v1:1.8.0        
docker pull    istio/examples-bookinfo-ratings-v1:1.8.0        
docker pull    istio/examples-bookinfo-reviews-v1:1.8.0        
docker pull    istio/examples-bookinfo-reviews-v2:1.8.0        
docker pull    istio/examples-bookinfo-reviews-v3:1.8.0        
docker pull    istio/examples-bookinfo-productpage-v1:1.8.0 

3.创建资源  kubectl apply -f istio-1.0.6/samples/bookinfo/platform/kube/bookinfo.yaml

4.kubectl get pods

5.kubectl get svc

6.测试一下是否成功

kubectl exec -it $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') -c ratings -- curl productpage:9080/productpage | grep -o "<title>.*</title>"

  成功显示如下:

通过ingress方式访问:

1.创建ingress规则,productpage-ingress.yaml

#ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: productpage-ingress
spec:
  rules:
  - host: productpage.istio.wuzz.com
    http:
      paths:
      - path: /
        backend:
          serviceName: productpage
          servicePort: 9080

   kubectl apply -f  productpage-ingress.yaml

  kubectl get ingress

2.访问测试 productpage.istio.wuzz.com ,记得用虚拟机的在本地hosts添加域名映射

通过istio的ingressgateway访问:

  官网:https://istio.io/docs/examples/bookinfo/#determine-the-ingress-ip-and-port

1.istio-1.0.6/samples/bookinfo/networking/bookinfo-gateway.yaml 可以查看一下该yaml文件,一个是Gateway,一个是VirtualService

  kubectl apply -f bookinfo-gateway.yaml

2.Confirm the gateway has been created:

  kubectl get gateway

3.set the INGRESS_HOST and INGRESS_PORT variables for accessing the gateway

export INGRESS_HOST=$(kubectl get po -l istio=ingressgateway -n istio-system -o jsonpath='{.items[0].status.hostIP}')
export INGRESS_PORT
=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')

4.Set GATEWAY_URL :

export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT

5.查看INGRESS_PORT端口  env | grep INGRESS_PORT  ,比如结果为31380

7.测试不断访问测试,发现会访问的review的不同版本,可以设置规则:

8.Apply default destination rules

  官网 :https://istio.io/docs/examples/bookinfo/#apply-default-destination-rules

  Before you can use Istio to control the Bookinfo version routing, you need to define the available versions, called subsets, in destination rules

  kubectl apply -f istio-1.0.6/samples/bookinfo/networking/destination-rule-all.yaml

体验Istio的流量管理:

  流量这块就体现了Pilot和Envoy的功能

基于版本的路由:

  官网 :https://istio.io/docs/tasks/traffic-management/request-routing/#apply-a-virtual-service

  之前刷新productpage页面的时候,发现review的版本一直会变,能不能一直访问某个版本呢?

   在 istio-1.0.6/samples/bookinfo/networking/ 目录下有很多的测试用的 yaml。

1.比如v3   istio-1.0.6/samples/bookinfo/networking/virtual-service-reviews-v3.yaml   kubectl apply -f virtual-service-reviews-v3.yaml   

2.再次访问测试:http://192.168.1.102:31380/productpage  一直在V3版本

基于用户身份的路由:

  官网 :https://istio.io/docs/tasks/traffic-management/request-routing/#route-based-on-user-identity

1.根据对应文件创建资源 istio-1.0.6/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml

2.测试:

# 使用jason来登录[右上角有Sign in的功能或者url?u=jason],一直会访问到v2版本
On the /productpage of the Bookinfo app, log in as user jason.
Refresh the browser. What do you see? The star ratings appear next to each
review.
# 使用其他用户登录,一直会访问到v1版本
Log in as another user (pick any name you wish).
Refresh the browser. Now the stars are gone. This is because traffic is routed
to reviews:v1 for all users except Jason.

基于权重的路由:

1.根据对应文件创建资源 istio-1.0.6/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml一半几率访问到v1,一半几率访问到v3,这里就相当于之前的蓝绿部署、AB测试或灰度发布,权重加起来必须是100

  kubectl apply -f virtual-service-reviews-50-v3.yaml

2.测试

故障注入:

  官网 :https://istio.io/docs/tasks/traffic-management/fault-injection/

1.创建一个故障注入规则,使得jason用户访问v2到ratings有7秒种的延迟

  kubectl apply -f virtual-service-ratings-test-delay.yaml

2.使用jason账户登录,并且访问productpage页面,会得到这样的一个返回信息 

  Error fetching product reviews!  Sorry, product reviews are currently unavailable for this book.

3.View the web page response times:

  Open the Developer Tools menu in you web browser.Open the Network tab   Reload the /productpage web page. You will see that the page actually loads in  about 6 seconds.

流量迁移:

  官网 :https://istio.io/docs/tasks/traffic-management/traffic-shifting/

1.让所有的流量都到v1

  kubectl apply -f virtual-service-all-v1.yaml

2.将v1的50%流量转移到v3

  kubectl apply -f virtual-service-reviews-50-v3.yaml

3.确保v3版本没问题之后,可以将流量都转移到v3

  kubectl apply -f virtual-service-reviews-v3.yaml

4.访问测试,看是否都访问的v3版本

体验Istio的Observe:

  这块就体现了Mixer和Envoy的功能

  通过 Mixer 收集数据汇报到  Prometheus。

收集Metrics:

  官网 :https://istio.io/docs/tasks/observability/metrics/collecting-metrics/

1.kubectl apply -f metrics-crd.yaml

# Configuration for metric instances
apiVersion: "config.istio.io/v1alpha2"
kind: instance
metadata:
  name: doublerequestcount
  namespace: istio-system
spec:
  compiledTemplate: metric
  params:
    value: "2" # count each request twice
    dimensions:
      reporter: conditional((context.reporter.kind | "inbound") == "outbound", "client", "server")
      source: source.workload.name | "unknown"
      destination: destination.workload.name | "unknown"
      message: '"twice the fun!"'
    monitored_resource_type: '"UNSPECIFIED"'
---
# Configuration for a Prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: prometheus
metadata:
  name: doublehandler
  namespace: istio-system
spec:
  metrics:
  - name: double_request_count # Prometheus metric name
    instance_name: doublerequestcount.instance.istio-system # Mixer instance name (fully-qualified)
    kind: COUNTER
    label_names:
    - reporter
    - source
    - destination
    - message
---
# Rule to send metric instances to a Prometheus handler
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: doubleprom
  namespace: istio-system
spec:
  actions:
  - handler: doublehandler.prometheus
    instances:
    - doublerequestcount

2.Send traffic to the sample application

  http://192.168.1.102:31380/productpage

3.创建ingress。访问prometheus

#ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: prometheus-ingress
  namespace: istio-system
spec:
  rules:
  - host: prometheus.istio.wuzz.com
    http:
      paths:
      - path: /
        backend:
          serviceName: prometheus
          servicePort: 9090

  http://prometheus.istio.wuzz.com

4.根据 istio_request_bytes_count 进行查询

5.Understanding the metrics configuration

  https://istio.io/docs/tasks/observability/metrics/collecting-metrics/#understanding-the-metrics-configuration

查询Istio的metrics

  官网 :https://istio.io/docs/tasks/observability/metrics/querying-metrics/

  This task shows you how to query for Istio Metrics using Prometheus. As part of this task, you will use the web-based interface for querying metric values.

1.访问productpage

  http://192.168.1.102:31380/productpage

2.打开prometheus界面

  http://prometheus.istio.wuzz.com

3.)输入查询指标

  istio_requests_total

4.About the Prometheus add-on

  https://istio.io/docs/tasks/observability/metrics/querying-metrics/#about-the-prometheus-add-on

分布式追踪之Jaeger:

  官网 :https://istio.io/docs/tasks/observability/distributed-tracing/overview/

1.查看jaeger的svc

  kubectl get svc -n istio-system | grep jae

  kubectl get svc jaeger-query -n istio-system -o yaml

2.配置jaeger的ingress jaeger-ingress.yaml

#ingress
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: jaeger-ingress
  namespace: istio-system
spec:
  rules:
  - host: jaeger.istio.itcrazy2016.com
    http:
      paths:
      - path: /
        backend:
          serviceName: jaeger-query
          servicePort: 16686

3.浏览器访问测试  jaeger.istio.wuzz.com ,就能看到调用链路。

4.发送100个请求 

for i in `seq 1 100`; do curl -s -o /dev/null http://192.168.1.102:31380/productpage; done

5.进入到jaeger界面选择productpage,查询详情

Mesh可视化之Kiali:

  官网 :https://istio.io/docs/tasks/observability/kiali/

Helm:

  官网 :https://istio.io/docs/setup/install/helm/  要使用 Helm 安装 Istio 参考官网。这也是推荐的

  Helm是Kubernetes的软件包管理工具,类似于Ubuntu中的apt、CentOS中的yum等。可以快速查找、下载和安装软件包,Helm由客户端组件helm和服务端组件tiller组成。解决的问题。比如在K8S中部署一个wordpress,需要创建deployment,service,secret、pv等。这些资源有时候不方便管理,过于分散,如果使用kubectl进行操作,发现还是比较恶心的。所以简单来说,helm就是为了解决上述问题。

  各种名词概念:

  • chart:helm的打包格式叫chart,chart即一系列文件,描述了一组相关的k8s集群资源
  • helm:客户端命令行工具,用于本地开发及管理chart、chart仓库等
  • tiller:helm的服务端,tiller接收helm的请求,与k8s的apiserver打交道,根据chart生成一个release并且管理release
  • release:helm install命令在k8s集群中部署的chart称为release
  • repository helm chart:helm客户端通过http协议来访问存储库中chart的索引文件和压缩包

  图解Helm原理:

  release操作

创建release
 (1)helm 客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息
 (2)helm 客户端指定的 chart 结构和 values 信息通过 gRPC 传递给 Tiller
 (3)Tiller 服务端根据 chart 和 values 生成一个 release
 (4)Tiller 将install release请求直接传递给 kube-apiserver
删除release
 (1)helm 客户端从指定的目录或本地tar文件或远程repo仓库解析出chart的结构信息
 (2)helm 客户端指定的 chart 结构和 values 信息通过 gRPC 传递给 Tiller
 (3)Tiller 服务端根据 chart 和 values 生成一个 release
 (4)Tiller 将delete release请求直接传递给 kube-apiserver
更新release
 (1)helm 客户端将需要更新的 chart 的 release 名称 chart 结构和 value 信息传给Tiller
 (2)Tiller 将收到的信息生成新的 release,并同时更新这个 release 的 history
 (3)Tiller 将新的 release 传递给 kube-apiserver 进行更新

安装Helm:

  以这个版本 helm-v2.13.1-linux-amd64.tar.gz 为例,

  • 放到k8s集群master节点解压tar -zxvf helm-v2.13.1-linux-amd64.tar.gz
  • 复制helm二进制到 bin目录下,并且配置环境变量查
    • cp linux-amd64/helm /usr/local/bin/
    • export PATH=$PATH:/usr/local/bin
  • 看是否安装成功  helm version

   这样子就成功了

安装Tiller:

  重新安装tiller:helm reset -f

1.安装tiller

  helm init --upgrade -i registry.cn-hangzhou.aliyuncs.com/google_containers/tiller:v2.13.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts

  kubectl get pods -n kube-system -l app=helm

  kubectl get svc -n kube-system -l app=helm

 

2.配置rbac

cat >helm-rbac-config.yaml<<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system
EOF

  kubectl create -f helm-rbac-config.yaml

  配置tiller使用创建的ServiceAccount

  kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

3.验证

  查看pod启动情况 kubectl get pod -n kube-system -l app=helm

  再次查看版本,显示出server版本  helm version

 使用helm操作chart

helm create:创建一个chart模板,比如:helm create test  --->ls test
helm package:打包一个chart模板,比如:helm package test  --->test-0.1.0.tgz
heml search:查找可用的chart模板,比如:helm search nginx
helm inspect:查看指定chart的基本信息,比如:helm inspect test
helm install:根据指定的chart部署一个release到k8s集群,比如:helm install test  --->get pods

chart模板
  chart文件结构

wordpress
├── charts              # 存放chart的定义
├── Chart.yaml            # 包含chart信息的yaml文件,如chart的版本、名称等
├── README.md             # chart的介绍信息
├── requirements.lock
├── requirements.yaml         # chart需要的依赖
├── templates             # k8s需要的资源
│  ├── deployment.yaml
│  ├── externaldb-secrets.yaml
│  ├── _helpers.tpl         # 存放可重用的模板片段
│  ├── ingress.yaml
│  ├── NOTES.txt
│  ├── pvc.yaml
│  ├── secrets.yaml
│  ├── svc.yaml
│  └── tls-secrets.yaml
└── values.yaml            # 当前chart的默认配置的值

  关于更多的 Helm的信息可以查看其官网 https://github.com/helm/helm/releases

原文地址:https://www.cnblogs.com/wuzhenzhao/p/12192066.html