Proxy在Istio架构中必须要有，Envoy是由Lyft开发并开源，使用C++编写的高性能代理，负责在服务网格中服务的进出流量。Istio使用Envoy代理的扩展版本。Envoy是用c++开发的高性能代理，用于协调服务网格中所有服务的所有入站和出站流量。Envoy代理是唯一与数据平面通信交互的Istio组件。Envoy代理被部署为服务的sidecars，在逻辑上增加了Envoy的许多内置特性，例如:
为什么选择Envoy?
对于Sidecar/Proxy其实不仅仅可以选择Envoy，还可以用Linkerd、Nginx和NginMesh等。像Nginx作为分布式架构中比较广泛使用的网关，Istio默认却没有选择，是因为Nginx没有Envoy优秀的配置扩展，Envoy可以实时配置。
Mixer在Istio架构中不是必须的，Mixer是一个独立于平台的组件。Mixer跨服务网格执行访问控制和使用策略，并从特使代理和其他服务收集遥测数据。代理提取请求级属性，并将它们发送到Mixer进行评估。Mixer包括一个灵活的插件模型。该模型使Istio能够与各种主机环境和基础设施后端进行交互。因此，Istio从这些细节中抽象出Envoy代理和Istio管理的服务。
Pilot在Istio架构中必须要有，Pilot为 Envoy sidecars 提供服务发现、用于智能路由的流量管理功能(例如，A/B测试、canary滚动等)和弹性(超时、重试、断路器等)。Pilot将控制流量行为的高级路由规则转换为特定于环境的配置，并在运行时将它们传播到sidecars。Pilot将特定于平台的服务发现机制抽象出来，并将它们合成为任何符合Envoy API的sidecar都可以使用的标准格式。下图显示了平台适配器和特使代理如何交互。
Galley在Istio架构中不是必须的,主要负责istio配置的校验、各种配置之间统筹，为istio提供配置管理服务。通过kubernetes的webhook机制对pilot和mixer的配置进行验证。
Citadel在Istio架构中不是必须的,Citadel支持强大的服务对服务和终端用户身份验证，内置身份和凭证管理。您可以使用Citadel来升级服务网格中的未加密流量。使用Citadel，运营商可以执行基于服务身份的策略，而不是相对不稳定的第3层或第4层网络标识。从0.5版开始，您可以使用Istio的授权特性来控制谁可以访问您的服务。在有一些场景中，对于安全要求是非常高的，比如支付，所以Citadel就是用来保证安全的。
官网：https://istio.io/docs/examples/bookinfo/
该应用程序由四个单独的微服务组成，用于演示各种Istio功能。该应用程序显示有关书籍的信息，类似于在线书籍商店的单个目录条目。页面上显示的是书的说明，书的详细信息（ISBN，页数等）和一些书评。Bookinfo应用程序分为四个单独的微服务：
productpage。该productpage微服务调用details和reviews微服务来填充页面。details。该details微服务包含图书信息。reviews。该reviews微服务包含了书评。它还称为ratings微服务。ratings。该ratings微服务包含预定伴随书评排名信息。 reviews微服务有3个版本：
ratings服务。ratings服务，并将每个等级显示为1到5个黑星。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 ""
成功显示如下：
通过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添加域名映射
官网：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
流量这块就体现了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版本
这块就体现了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
官网 ：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，查询详情
官网 ：https://istio.io/docs/tasks/observability/kiali/
官网 ：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就是为了解决上述问题。
各种名词概念：
图解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-v2.13.1-linux-amd64.tar.gz 为例，
这样子就成功了
重新安装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
京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有