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微服务调用details和reviews微服务来填充页面。
• 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