istio 配置解读

最新推荐文章于 2024-03-19 09:10:22 发布
最新推荐文章于 2024-03-19 09:10:22 发布
阅读量482 收藏 1
点赞数
文章标签： 运维 数据库 awk
原文链接：http://www.cnblogs.com/fengjian2016/p/8365081.html
版权

Istio在服务网络中统一提供了许多关键功能：

  • 流量管理：控制服务之间的流量和API调用的流向，使得调用更可靠，并使网络在恶劣情况下更加健壮。

  • 可观察性：了解服务之间的依赖关系，以及它们之间流量的本质和流向，从而提供快速识别问题的能力。

  • 策略执行：将组织策略应用于服务之间的互动，确保访问策略得以执行，资源在消费者之间良好分配。策略的更改是通过配置网格而不是修改应用程序代码。

  • 服务身份和安全：为网格中的服务提供可验证身份，并提供保护服务流量的能力，使其可以在不同可信度的网络上流转。

 

Istio针对可扩展性进行了设计，以满足不同的部署需要：

  • 平台支持：Istio旨在在各种环境中运行，包括跨云， 预置，Kubernetes，Mesos等。最初专注于Kubernetes，但很快将支持其他环境。

  • 集成和定制：策略执行组件可以扩展和定制，以便与现有的ACL，日志，监控，配额，审核等解决方案集成。

 

 

Envoy：

　　　　istio 使用Envoy 代理的扩展版本，Envoy是以c++开发的高性能代理，用于解释服务网格中所有服务的所有入站和出站的流量，Envoy的许多内置功能被iosio发扬光大，例如动态发现，负载均衡，TLS终止，HTTP1/2&Grpc代理，熔断器，健康检查，基于百分比流量拆分的分段推出，故障注入和丰富指标。

　　　　Envoy被部署为边车，和对应服务在同一个pod中，这允许istio将大量关于流量行为的型号作为属性提取出来，而这些属性又可以在Mixer中用于执行策略决策，并发送到监控系统，以提供整个网格行为的信息

 

Mixer：

　　　　负责在服务网格上执行访问控制和使用策略，并从Envoy代理和其他服务收集遥测数据，代理提取请求级属性，发送到Mixer进行评估。

 

Pilot

　　　负责手机和验证配置，并将其传播到各种istio组件，它从Mixer和Envoy中提取环境特定的实现细节，为他们提供用户服务的抽象表示，独立于底层平台，此外，流量管理规则可以在运行时通过pilot进行编程。

 

lstio-auth

　　　　 提供强大的服务间认证和终端用户认证，使用交互tls，内置身份和证书管理，可以升级服务网格中的未加密流量，并为运维人员提供基于服务身份而不是网络控制来执行策略的能力。

 

 

 

安装Istio Sidecar

 在Kubernetes 1.9及更高版本中默认启用。从Istio 0.5.0开始，自动代理注入使用突变webhooks，并且已经删除了对初始化程序注入的支持。无法升级到Kubernetes 1.9的用户应使用手动注入。

 

自动把 sidecar 插入到 pod中， 需要在api中打开 

 

[root@master1 addons]# cat /lib/systemd/system/kube-apiserver.service 
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/GoogleCloudPlatform/kubernetes
After=network.target

[Service]
User=root
ExecStart=/usr/local/bin/kube-apiserver \
  --admission-control=Initializers,NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,NodeRestriction,ResourceQuota,,MutatingAdmissionWebhook,ValidatingAdmissionWebhook \ --advertise-address=192.168.200.51 \ --allow-privileged=true \ --anonymous-auth=false \ --apiserver-count=1 \ --audit-policy-file=/etc/kubernetes/audit-policy.yaml \ --audit-log-maxage=30 \ --audit-log-maxbackup=3 \ --audit-log-maxsize=100 \ --audit-log-path=/var/log/kubernetes/audit.log \ --authorization-mode=Node,RBAC \ --bind-address=0.0.0.0 \ --secure-port=6443 \ --client-ca-file=/etc/kubernetes/ssl/ca.pem \ --enable-swagger-ui=true \ --etcd-cafile=/etc/kubernetes/ssl/ca.pem \ --etcd-certfile=/etc/kubernetes/ssl/kubernetes.pem \ --etcd-keyfile=/etc/kubernetes/ssl/kubernetes-key.pem \ --etcd-servers=https://192.168.200.51:2379,https://192.168.200.52:2379,https://192.168.200.53:2379 \ --event-ttl=1h \ --kubelet-https=true \ --insecure-bind-address=192.168.200.51 \ --insecure-port=8080 \ --service-account-key-file=/etc/kubernetes/ssl/ca-key.pem \ --service-cluster-ip-range=10.254.0.0/16 \ --service-node-port-range=30000-32000 \ --tls-cert-file=/etc/kubernetes/ssl/kubernetes.pem \ --tls-private-key-file=/etc/kubernetes/ssl/kubernetes-key.pem \ --enable-bootstrap-token-auth=true \ --token-auth-file=/etc/kubernetes/token.csv \ --requestheader-client-ca-file=/etc/kubernetes/ssl/front-proxy-ca.pem \ --proxy-client-cert-file=/etc/kubernetes/ssl/front-proxy-client.pem \ --proxy-client-key-file=/etc/kubernetes/ssl/front-proxy-client-key.pem \ --requestheader-allowed-names=aggregator \ --requestheader-group-headers=X-Remote-Group \ --requestheader-extra-headers-prefix=X-Remote-Extra- \ --requestheader-username-headers=X-Remote-User \ --runtime-config=admissionregistration.k8s.io/v1alpha1 \ --runtime-config=api/all=true \ --enable-aggregator-routing=true \ --v=0 Restart=on-failure RestartSec=5 Type=notify LimitNOFILE=65536 [Install] WantedBy=multi-user.target

 

 

 

Pod规格要求

1.服务关联

2.命名端口

服务端口必须命名。端口名称必须是形式<protocol>[-<suffix>]与 HTTP， http2， GRPC，或 Redis的作为<protocol>，以便采取的Istio的路由功能。例如，name: http2-foo或者name: http是有效的端口名称，但name: http2foo不是。如果端口名称未以可识别的前缀开头，或者端口未命名，则端口上的流量将被视为纯TCP流量（除非端口明确用于Protocol: UDP表示UDP端口

 

3. 使用应用标签进行部署：建议使用Kubernetes部署的Pod在部署规范中Deployment具有明确的app标签。每个部署规范都应该有一个明确的app标签，其中有一个值表示有意义的值 该app标签用于在分布式跟踪中添加上下文信息

 

自动边车注入

使用webhook准入控制器，可将Sidecars自动添加到适用的Kubernetes Pod中。此功能需要Kubernetes 1.9或更高版本。验证kube-apiserver进程是否已设置admission-control标记，MutatingAdmissionWebhook并ValidatingAdmissionWebhook按照正确的顺序添加并准许控制器，并且启用许可注册API。

kubectl api-versions | grep admissionregistration
admissionregistration.k8s.io/v1beta1

 

安装webhook
kubectl apply -f install/kubernetes/istio.yaml

 

Webhooks需要签名的证书/密钥对。使用install/kubernetes/webhook-create-signed-cert.sh来产生由Kubernetes' CA签名的证书/密钥对 生成的证书/密钥文件作为Kubernetes机密文件存储，供边车注入器webhook使用。

注意：Kubernetes CA批准需要创建和批准CSR的权限

./install/kubernetes/webhook-create-signed-cert.sh \
    --service istio-sidecar-injector \
    --namespace istio-system \
    --secret sidecar-injector-certs

 

安装边车注入配置图。

kubectl apply -f install/kubernetes/istio-sidecar-injector-configmap-release.yaml

 

Set the caBundle in the webhook install YAML that the Kubernetes api-server uses to invoke the webhook.

cat install/kubernetes/istio-sidecar-injector.yaml | \
     ./install/kubernetes/webhook-patch-ca-bundle.sh > \
     install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml

 

Install the sidecar injector webhook.

kubectl apply -f install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml

 

The sidecar injector webhook should now be running.

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

 

NamespaceSelector根据该对象的名称空间是否与选择器匹配来决定是否在对象上运行webhook,默认的webhook配置使用istio-injection=enabled。

查看显示istio-injection标签的default名称空间并验证名称空间未被标记。

kubectl get namespace -L istio-injection

NAME           STATUS        AGE       ISTIO-INJECTION
default        Active        1h        
istio-system   Active        1h        
kube-public    Active        1h        
kube-system    Active        1h

 

用default名称空间标签istio-injection=enabled

kubectl label namespace default istio-injection=enabled
kubectl get namespace -L istio-injection

NAME           STATUS    AGE       ISTIO-INJECTION
default        Active    1h        enabled
istio-system   Active    1h        
kube-public    Active    1h        
kube-system    Active    1h

 

部署一个应用程序
kubectl apply -f samples/sleep/sleep.yaml

 

 

禁用default名称空间的注入

kubectl label namespace default istio-injection-

 

 

卸载webhook
kubectl delete -f install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml

 

kubectl -n istio-system delete secret sidecar-injector-certs
kubectl delete csr istio-sidecar-injector.istio-system
kubectl label namespace default istio-injection-

 

 

 

流量管理
介绍演示Istio服务网格的流量路由功能的任务。

配置请求路由:　　此任务向您展示如何根据权重和HTTP标头配置动态请求路由。
故障注入　　:　　此任务显示如何注入延迟并测试应用程序的弹性。
交通转移　　:　　此任务向您显示如何将流量从旧版本迁移到新版本的服务。
设置请求超时:　　本任务向您展示如何使用Istio在Envoy中设置请求超时。
Istio Ingress  :　　介绍如何在Kubernetes上配置Istio Ingress。
控制出口流量:　　介绍如何配置Istio以将流量从网格中的服务路由到外部服务。
控制出口TCP流量:介绍如何配置Istio以将TCP流量从网格中的服务路由到外部服务。
断路　　　　:　　这项任务演示了弹性应用的断路能力
镜像　　　　:　　演示Istio的流量投影/镜像功能

 

 

 deployment 和 service 模版 ，使用标签 app version， 一个服务对应不同的deployment

apiVersion: v1
kind: Service
metadata:
  name: reviews
  labels:
    app: reviews
spec:
  type: NodePort
  ports:
  - port: 9080
    name: http
  selector:
    app: reviews
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: reviews-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: reviews
        version: v1
    spec:
      containers:
      - name: reviews
        image:  192.168.200.10/istio/examples-bookinfo-reviews-v1:1.5.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: reviews-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: reviews
        version: v2
    spec:
      containers:
      - name: reviews
        image:  192.168.200.10/istio/examples-bookinfo-reviews-v2:1.5.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: reviews-v3
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: reviews
        version: v3
    spec:
      containers:
      - name: reviews
        image:  192.168.200.10/istio/examples-bookinfo-reviews-v3:1.5.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080

 

配置请求路由

 

原理： 首先使用istio将100%的请求流量路由到了 v1 版本上， 然后设置了一条路由规则， 该规则基于请求header（一个用户的cookie）将流量路由到了 v2 版本，  如果v2 版本经过测试后满足要求，我们就可以一次性

或者渐进的路由到v2版本上。

 

1. 默认访问 version v1 版本

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1

 

2. 将特定用户的请求路由到 version v2上

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-test-v2
spec:
  destination:
    name: reviews
  precedence: 2
  match:
    request:
      headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
  route:
  - labels:
      version: v2

 

 

故障注入

istio 注入延迟 测试应用弹性

2个服务， serverA  和 serverB

serverA 用户(feng) 和 serverB 之间 注入7秒延迟，    serverA 针对 serverB 服务设置了10秒超时，期望 端对端的流程能无错持续。

 注意： 其他用户没有注入7秒延迟。

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: ratings-test-delay
spec:
  destination:
    name: ratings
  precedence: 2
  match:
    request:
      headers:
        cookie:
          regex: "^(.*?;)?(user=jason)(;.*)?$"
  route:
  - labels:
      version: v1
  httpFault:
    delay:
      percent: 100
      fixedDelay: 7s

 

使用账户 feng 登录， 如果应用首页已经设置了正确处理延迟，那么首页将会在 7秒加载完成，但是 serverA 到 serverB 需要等待10秒，那么将超时。

 

 流量转移：

应用流量 逐步有旧版本的服务 迁移到新版本， 通过istio 可以使用不同权重的规则，将流量平稳的从旧版本服务 迁移到新版本上， 金丝雀 灰度发布。

 1. 请求v1 版本

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1

 

 2. 把50% 的流量从 v1 版本 转移到 v3版本

 

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1
    weight: 50
  - labels:
      version: v3
    weight: 50

用 kubectl  apply/ replace 替换

 

3. v3 和 v1 版本交替出现后， 将100%的流量路由到v3 版本中

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v3
    weight: 100

 

 

 ###################################################################################################

 实战：

一个服务，对应3个deployment， 最后通过istio-ingress 映射域名

 

nginx.yaml

apiVersion: v1
kind: Service
metadata:
  namespace: fengjian
  name: nginx
  labels:
    app: nginx
spec:
  type: NodePort
  ports:
  - port: 80
    name: http
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: fengjian
  name: nginx-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
        version: v1
    spec:
      containers:
      - name: nginx
        image:  192.168.200.10/test/nginx:v1
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: fengjian
  name: nginx-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
        version: v2
    spec:
      containers:
      - name: nginx
        image:  192.168.200.10/test/nginx:v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  namespace: fengjian
  name: nginx-v3
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
        version: v3
    spec:
      containers:
      - name: nginx
        image:  192.168.200.10/test/nginx:v3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 80

 

2. 通过istio-ingress 让外网访问，注意： pod 注入 enovy后，nodeport 不起作用了，服务无法访问。

istio-ingress-bookinfo.yaml 

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gatewayfengjian
  namespace: fengjian
  annotations:
    kubernetes.io/ingress.class: "istio"
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 80

 

创建执行

[root@master1 nginx-istio]# kubectl create -f booktest.yaml  -f istio-ingress-bookinfo.yaml

 

 

 默认情况， 访问应该轮训到 3个deployment的上的nginx ,  通过流量管理中的 配置请求路由规则，指定到 deployment  nginx：v1 版本上

vim rule-choice-deployment-nginx-v1.yaml

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  namespace: fengjian
  name: nginx-default
spec:
  destination:
    name: nginx
  precedence: 1
  route:
  - labels:
      version: v1

 

创建规则

kubectl create -f rule-choice-deployment-nginx-v1.yaml

 

 访问istio-ingress 

 

 注意的问题： 

 

 

 

流量转移

流量从 旧版本中迁移到新版本中， 通过istio，可以使用一系列不同权重的规则(10%,20%.....100%),将流量平稳的迁移到新版本中

1. 迁移50%到新版本中

route-rule-reviews-50.yaml

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  namespace: fengjian
  name: nginx-50
spec:
  destination:
    name: nginx
  precedence: 1
  route:
  - labels:
      version: v1
    weight: 50
  - labels:
      version: v3
    weight: 50

 

通过访问页面，基本上是50%的轮训到页面。

 

2. 迁移100%到新版本中

route-rule-reviews-100.yaml

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  namespace: fengjian
  name: nginx-50
spec:
  destination:
    name: nginx
  precedence: 1
  - labels:
      version: v3
    weight: 100

 

 是更新，不是创建

kubectl apply -f route-rule-reviews-100.yaml

 

 注意该方式和使用容器编排平台的部署特点来进行版本迁移是完全不同的，容器编排平台使用了实例scaling来对流量进行管理，而通过istio，两个版本的的服务可以独立进行

scale up 和 scale down，并不会影响这两个版本的服务之间的流量分发。

 

 

 熔断

限制因为故障、延迟高峰以及其他预计外的网络异常所造成的影响范围。

服务端使用 nginx

 

 

配置目的策略，对nginx 的调用过程进行断路设置。

 

nginx-destinaionpolicy.yaml

apiVersion: config.istio.io/v1beta1
kind: DestinationPolicy
metadata:
 name: nginx-circuit-breaker
spec:
 destination:
   name: nginx
   labels:
     version: v1
 circuitBreaker:
   simpleCb:
     maxConnections: 1
     httpMaxPendingRequests: 1
     sleepWindow: 3m
     httpDetectionInterval: 1s
     httpMaxEjectionPercent: 100
     httpConsecutiveErrors: 1
     httpMaxRequestsPerConnection: 1

 

kubectl  create -f  nginx-destinaionpolicy.yaml

istioctl get destinationpolicy

NAME                    KIND                                            NAMESPACE
nginx-circuit-breaker DestinationPolicy.v1alpha2.config.istio.io        istio-samples

 

设置客户端

客户端调用ginx服务的规则， 创建一个客户端，向服务端发送流量， 使用负载测试工具fortio, 使用fortio 可以控制连接数量，并发数以及外发http调用的延迟。

kubectl apply -f <(istioctl kube-inject -f samples/httpbin/sample-client/fortio-deploy.yaml)

 

使用-curl 指定只执行一次调用。

FORTIO_POD=$(kubectl get pod | grep fortio | awk '{ print $1 }')
kubectl exec -it $FORTIO_POD  -c fortio /usr/local/bin/fortio -- load -curl  http://nginx:8000

 

测试断路器

在断路器设置中，我们指定maxConnections: 1以及httpMaxPendingRequests: 1。这样的设置下，如果我们并发超过一个连接和请求，istio-proxy就会断掉后续的请求和连接。设置两个并发链接（-c 2），发送20个请求（-n 20）：

[root@master1 httpbin]# kubectl exec -it fortio-deploy-d86464f9d-ks4hm   -c fortio /usr/local/bin/fortio -- load -c 2 -qps 0 -n 20 -loglevel Warning http://nginx.fengjian
08:10:21 I logger.go:97> Log level is now 3 Warning (was 2 Info)
Fortio 0.9.0 running at 0 queries per second, 4->4 procs, for 20 calls: http://nginx.fengjian
Starting at max qps with 2 thread(s) [gomax 4] for exactly 20 calls (10 per thread + 0)
Ended after 18.157183ms : 20 calls. qps=1101.5
Aggregated Function Time : count 20 avg 0.0016854434 +/- 0.0008323 min 0.000847509 max 0.004309432 sum 0.033708867
# range, mid point, percentile, count
>= 0.000847509 <= 0.001 , 0.000923755 , 15.00, 3
> 0.001 <= 0.002 , 0.0015 , 65.00, 10
> 0.002 <= 0.003 , 0.0025 , 95.00, 6
> 0.004 <= 0.00430943 , 0.00415472 , 100.00, 1
# target 50% 0.0017
# target 75% 0.00233333
# target 90% 0.00283333
# target 99% 0.00424755
# target 99.9% 0.00430324
Sockets used: 2 (for perfect keepalive, would be 2)
Code 200 : 20 (100.0 %)
Response Header Sizes : count 20 avg 237 +/- 0 min 237 max 237 sum 4740
Response Body/Total Sizes : count 20 avg 246 +/- 0 min 246 max 246 sum 4920
All done 20 calls (plus 0 warmup) 1.685 ms avg, 1101.5 qps

 

 

设置两个并发链接（-c 100000），发送20个请求（-n 200000）

kubectl exec -it fortio-deploy-d86464f9d-ks4hm   -c fortio /usr/local/bin/fortio -- load -c 100000 -qps 0 -n 20000 -loglevel Warning http://nginx.fengjian

> 50 <= 75 , 62.5 , 42.37, 12001
> 75 <= 100 , 87.5 , 47.88, 5515
> 100 <= 283.465 , 191.733 , 100.00, 52118
# target 50% 107.452
# target 75% 195.459
# target 90% 248.263
# target 99% 279.945
# target 99.9% 283.113
Sockets used: 100001 (for perfect keepalive, would be 100000)
Code  -1 : 62857 (62.9 %)
Code 200 : 19587 (19.6 %)
Code 503 : 17558 (17.6 %)
Response Header Sizes : count 100002 avg 46.731345 +/- 94.69 min 0 max 240 sum 4673228
Response Body/Total Sizes : count 100002 avg 86.594238 +/- 113 min 0 max 249 sum 8659597
All done 100002 calls (plus 0 warmup) 123391.636 ms avg, 352.1 qps

 

 

策略实施

限流

如果是一个外部付费API服务， 限制1 qps免费， 使用istio 控制。

 

转载于:https://www.cnblogs.com/fengjian2016/p/8365081.html

weixin_30566149
关注
  • 0
    点赞
  • 踩
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
k8s环境Istio应用详解
03-21
内容主要包含了k8s环境下istio的安装教程，以及istio相关案例。同时包含灰度发布以及流量治理等相关内容
istio-ui:istio配置管理后台，停止维护。https
03-19
istio-ui用于管理istio配置，目的是简化运维的配置工作。主要实现：注入，istio配置和模板（还在开发中）等功能。 为了保证注入和配置的原生性，参考和使用了istio的源码。 三种注入方式 一键注入 基于运行中的服务...
Istio详解
Dusttang的博客
06-21 3339
纪念第一次写博客
Istio：搭建Istio完整环境
最新发布
weixin_42335634的博客
03-19 1804
本文基于官方安装文档和最新版（1.20.2）部署了完整的Istio环境（Bookinfo、kiali、jaeger、grafana、loki）。
【云原生 | 从零开始学istio】三、istio组件详解
欢迎关注，一起进步！
10-23 1633
istio的组件详细解读
Istio中如何限流？
MyySophia的博客
05-31 604
基于 QPS 的限流：可以使用 Istio 中的 Mixer 配置来设置基于 QPS 的限流。在 Istio 中，可以使用 Envoy 的内置限流机制来限制服务的流量。基于连接数的限流：可以使用 Envoy 的内置连接管理器来设置基于连接数的限流。上面的示例中，设置了一个名为 requestcountquota 的限流规则，它将每秒钟的请求数限制为100。总之，Istio 的限流机制可以帮助您更好地管理服务的流量，从而提高应用程序的可靠性和性能。上面的示例中，将最大连接数设置为 100。
Istio介绍
qq_42747099的博客
04-01 1228
服务网格 服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。 服务网格的工作 Istio 将服务请求路由到目的地址，根据中的参数判断是到生产环...
istio学习(四)Istio服务治理-负载均衡模型介绍
文若书生的专栏
11-18 630
Istio提供了三种负载均衡策略：simple、consistentHash、localityLbSetting，下面一一介绍。名称描述simple简单方式，其内置了四种负载均衡算法基于HASH一致性算法的负载均衡局部负载均衡器设置，将完全覆盖网格的设置。
Cookies与Session
Mikon_0703
05-23 231
静态网页 html页面，后缀为.html，可以直接部署到web容器，在浏览器端通过链接访问。常用的web容器有：Nginx、Apache、Tomcat等 动态网页 动态网页可以解析URL中的参数，或者关联数据库中的数据，显示不同网页内容。由jsp、php等语言编写 Session 会话，产生在服务端，用来保存当前用户的会话信息 Cookies 保存在浏览器（客户端），当用户（浏览器）再次访问服务端的时候，将此cookies带上，这时候，服务端可以通过Cookies识别...
带你玩转Istio-第3篇---Istio架构概述篇
坚持的道路注定孤独
09-26 7241
Istio架构概述 前面的内容分别讲解了Istio是什么，以及Istio能做什么。本章将在此基础上进行Istio的架构概述，包括 Istio 的工作机制、服务模型和主要组件，为学习流量治理、策略与遥测、访问安全等内容做必要的知识储备。 2.1 Istio的工作机制 图2-1展示了Istio的工作机制和架构，分为控制面和数据面两部分。可以看到，控制面主要包括Pilot、Mixer、Citade...
Istio路由规则配置：VirtualService概念及HTTPRoute讲解
WuYuChen20的博客
05-05 1万+
Istio路由规则配置：VirtualService概念及HTTPRoute讲解1.1 路由规则配置示例1.2 路由规则定义1.3 HTTP路由（HTTPRoute）1）HTTPRoute规则解析2）HTTP匹配规则（HTTPMatchRequest）3）HTTP路由目标（HTTPRouteDestination）4）HTTP重定向（HTTPRedirect）5）HTTP重写（HTTPRewrit...
istio使用教程和示例（导流，请求路由，访问拒绝，黑白名单，限速）
热门推荐
全栈工程师开发手册（原创）https://github.com/tencentmusic/cube-studio
11-28 1万+
我们先下载下来istio的压缩包，其中samples目录中包含使用示例，我们使用其中的Bookinfo应用 使用下面命令可以创建Bookinfo应用的组件 kubectl create ns istio-demo kubectl create -f &amp;amp;amp;amp;amp;amp;lt;(istioctl kube-inject -f samples/bookinfo/platform/kube/bookinfo.yaml)...
istio配置请求速率限制.pdf
09-20
istio配置请求速率限制.pdf
istio-vet:验证Kubernetes集群中Istio配置的实用程序
05-07
istio-vet工具是一个实用程序，用于验证在集群中安装的和用户应用程序的配置。 此工具适用于Istio 0.7.1及更高版本。 介绍 istio-vet实用程序可帮助发现kubernetes集群中用户应用程序和Istio组件的不兼容配置。 ...
istio1.15.tar
09-15
istio版本使用的1.5.5
istio-1.7.3
10-26
解决国内网络无法下载，解压后可正常使用，无需执行官网的下载链接 下载 Istio，下载内容将包含：安装文件、示例和 istioctl 命令行工具。
Istio如何使用相同的端口访问网格外服务
weixin_34032792的博客
12-26 179
1.1、背景 写这篇文章的目的是为了说明以下问题：如何使用TCP协议相同的端口访问网格外多个服务？ 这是最近直播的时候有一个同学提出的，当时我没有完全明白，“访问多集群” 的意思。后来仔细思考了一下，问题应该就是Istio服务网格内如何通过相同的协议，端口访问不同的服务。 1.2、使用场景 肯定会有人回答，既然相同的端口不能使用，何不换一个端口呢，这样做也是一种解决方法。我在想有一些场景一定没法或...
各种服务名称和对应端口号
都是曾经而已
10-10 5636
端口：0  服务：Reserved  说明：通常用于分析操作系统。这一方法能够工作是因为在一些系统中“0”是无效端口，当你试图使用通常的闭合端口连接它时将产生不同的结果。一种典型的扫描，使用IP地址为0.0.0.0，设置ACK位并在以太网层广播。  端口：1  服务：tcpmux  说明：这显示有人在寻找SGI Irix机器。Irix是实现tcpmux的主要提供者，默认情况下tcpm
istio学习笔记之流量管理
丰耳的博客
07-18 919
按照实际用例解释istio流量管理的使用方法，包含熔断、限流、超时、重试、流量转移等等
istio 双栈配置 yaml
06-11
以下是一个基本的 Istio 双栈配置 YAML 文件示例： ```yaml apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: my-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" - port: number: 443 name: https protocol: HTTPS hosts: - "*" --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: my-destination-rule spec: host: my-service trafficPolicy: loadBalancer: simple: ROUND_ROBIN portLevelSettings: - port: number: 80 address: ::/0 # IPv6地址，用于双栈配置 - port: number: 80 address: 0.0.0.0/0 # IPv4地址，用于双栈配置 --- apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-virtual-service spec: hosts: - my-service http: - route: - destination: host: my-service port: number: 80 subset: v1 ``` 在这个 YAML 文件中，我们定义了一个名为 `my-gateway` 的 Istio Gateway 对象，它将接受所有的 HTTP 和 HTTPS 流量。我们还定义了一个名为 `my-destination-rule` 的 DestinationRule 对象，它将负载均衡到 `my-service` 上，并支持 IPv4 和 IPv6 地址。最后，我们定义了一个名为 `my-virtual-service` 的 VirtualService 对象，它将所有的 HTTP 流量路由到 `my-service` 上。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值