運(yùn)維調(diào)試:Istio

可觀(guān)察性

Istio 生成以下類(lèi)型的 telemetry(遙測(cè)信息) ，以提供整體服務(wù)網(wǎng)格可觀(guān)察性：

  • Metrics
    Istio 根據(jù)監(jiān)視的四個(gè)“黃金信號(hào)”（ latency(延遲) 、 traffic(流量) 、 errors 、 saturation(飽和度) ） 為服務(wù)生成一組指標(biāo)數(shù)據(jù)。
    Istio 還為網(wǎng)格控制平面 提供了的詳細(xì)的指標(biāo)數(shù)據(jù)。
    還基于這些指標(biāo)構(gòu)建了一組內(nèi)置的網(wǎng)格監(jiān)視儀表板。
    metrics的收集從sidecar代理(Envoy)開(kāi)始, Envoy自身也有很豐富的metrics統(tǒng)計(jì)信息。這被稱(chēng)為 Proxy-level metrics
    除了 Proxy-level metrics , Istio 還提供了一組 面向服務(wù) 的metrics，就是上述的 latency(延遲) 、 traffic(流量) 、 errors 、 saturation(飽和度) 。 這被稱(chēng)為 Service-level metrics
    啟用 Service-level metrics 是可選的，運(yùn)維人員可以選擇關(guān)閉這些指標(biāo)的生成和收集，以滿(mǎn)足他們的個(gè)性化需求。

  • Distributed Traces
    Istio 為每個(gè)服務(wù)生成分布式追蹤span，從而使運(yùn)維人員能夠詳細(xì)了解網(wǎng)格內(nèi)的服務(wù)調(diào)用鏈和服務(wù)之間的依賴(lài)性

  • Access Logs
    當(dāng)流量進(jìn)入網(wǎng)格內(nèi)的服務(wù)時(shí)， Istio 可以為每個(gè)請(qǐng)求生成完整的記錄，包含源和目標(biāo)的metadata。
    該信息可以使運(yùn)維人員審計(jì)在單個(gè)工作負(fù)載的級(jí)別上審計(jì)服務(wù)的行為。

啟用 Envoy的訪(fǎng)問(wèn)日志

在 IstioOperator CR 中增加如下配置：

spec:
  meshConfig:
    accessLogFile: /dev/stdout

流量管理方面的常見(jiàn)問(wèn)題

Requests被Envoy拒絕

Requests可能由于各種原因而被拒絕。 理解為什么拒絕請(qǐng)求的最佳方法是檢查 Envoy的訪(fǎng)問(wèn)日志 。 默認(rèn)情況下，訪(fǎng)問(wèn)日志輸出到容器的標(biāo)準(zhǔn)輸出。 運(yùn)行以下命令以查看日志：

kubectl logs PODNAME -c istio-proxy -n NAMESPACE

在默認(rèn)訪(fǎng)問(wèn)日志默認(rèn)格式中，在返回碼后面有 Envoy response flags 和 Mixer policy status 。
如果您使用的是自定義日志格式，請(qǐng)確保包括 %RESPONSE_FLAGS% 和 %DYNAMIC_METADATA(istio.mixer:status)%

常見(jiàn)的 response flags 有:

  • NR : No Route configured , 檢查 DestinationRule 或 VirtualService
  • UO : Upstream overflow with circuit breaking, 檢查 DestinationRule 中的斷路器配置
  • UF : Upstream Failed . 如果你正在使用 Istio 認(rèn)證，檢查 mTLS配置沖突
  • UAEX : 表示request是被 Mixer 拒絕的（Mixer policy status的值不能是 - ）

常見(jiàn)的 Mixer Policy status 有:

  • UNAVAILABLE : Envoy不能連接到Mixer并且Policy被配置為Fail Close
  • UNAUTHENTICATED : 請(qǐng)求被 Mixer authentication 拒絕
  • PERMISSION_DENIED : 請(qǐng)求被 Mixer authorization 拒絕
  • RESOURCE_EXHAUSTED : 請(qǐng)求被 Mixer quota 拒絕
  • INTERNAL : 請(qǐng)求被拒絕因?yàn)?Mixer內(nèi)部錯(cuò)誤

路由規(guī)則似乎沒(méi)有影響traffic flow

Envoy的當(dāng)前版本實(shí)現(xiàn)中，可能需要多達(dá)100個(gè)請(qǐng)求才能遵守按權(quán)重分發(fā)流量
如果路由規(guī)則對(duì)于Bookinfo示例而言運(yùn)行良好,但是類(lèi)似的“版本路由規(guī)則”對(duì)您自己的應(yīng)用程序沒(méi)有影響，則可能需要您對(duì)您的Kubernetes服務(wù)需要稍作更改。
Kubernetes服務(wù)必須遵守某些限制，才能利用 Istio 的L7路由功能。 有關(guān)詳細(xì)信息，請(qǐng)參閱Pod和服務(wù)要求。

另一個(gè)潛在的可能是路線(xiàn)規(guī)則的生效速度有些緩慢。 Kubernetes上的 Istio實(shí)現(xiàn) 使用 最終一致的算法 來(lái)確保所有Envoy sidecar具有一致的配置，包括所有路由規(guī)則。 配置更改將需要一些時(shí)間才能傳播到所有 sidecars。 在大型部署中，傳播將花費(fèi)更長(zhǎng)的時(shí)間，并且可能會(huì)有幾秒鐘的延遲時(shí)間。

在設(shè)置了Destination rule之后返回HTTP 503錯(cuò)誤

如果在應(yīng)用DestinationRule后對(duì)服務(wù)的請(qǐng)求立即生成 HTTP 503錯(cuò)誤 ，并且錯(cuò)誤一直持續(xù)到您刪除或還原DestinationRule，則DestinationRule可能會(huì)導(dǎo)致服務(wù)的 TLS沖突 。
例如，如果你在集群全局配置了雙向TLS，那么 DestinationRule必須包含如下的 trafficPolicy :

trafficPolicy:
  tls:
    mode: ISTIO_MUTUAL

否則， mode 的默認(rèn)值是 DISABLE ， 將導(dǎo)致客戶(hù)端的 proxy sidecar 發(fā)出純HTTP請(qǐng)求而不是TLS加密請(qǐng)求。 因?yàn)榉?wù)端的 proxy sidecar 期望加密的請(qǐng)求，所以客戶(hù)端代理發(fā)出的請(qǐng)求與服務(wù)端代理期望接受的請(qǐng)求發(fā)生沖突。

每當(dāng)您應(yīng)用DestinationRule時(shí)，請(qǐng)確保 trafficPolicy TLS模式 與全局配置匹配。

路由規(guī)則對(duì)ingress gateway上的請(qǐng)求無(wú)效

假設(shè)您使用 ingress gateway 和相應(yīng)的VirtualService訪(fǎng)問(wèn)內(nèi)部服務(wù)。 例如，您的VirtualService看起來(lái)像這樣：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - "myapp.com" # or maybe "*" if you are testing without DNS using the ingress-gateway IP (e.g., http://1.2.3.4/hello)
  gateways:
  - myapp-gateway
  http:
  - match:
    - uri:
        prefix: /hello
    route:
    - destination:
        host: helloworld.default.svc.cluster.local

你還有一個(gè) VirutalService 定義將流量路由到特定的subset,如下所示:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: helloworld
spec:
  hosts:
  - helloworld.default.svc.cluster.local
  http:
  - route:
    - destination:
        host: helloworld.default.svc.cluster.local
        subset: v1

在這種情況下，您會(huì)注意到，通過(guò)入口網(wǎng)關(guān)向helloworld服務(wù)的請(qǐng)求將不會(huì)定向到子集v1，而是將繼續(xù)使用默認(rèn)的 round-robin routing(輪詢(xún)路由) 。
以 gateway host（例如myapp.com）作為入口的請(qǐng)求將激活 myapp VirtualService 中的規(guī)則，該規(guī)則會(huì)將流量路由到helloworld服務(wù)的任意endpoint。
以 helloworld.default.svc.cluster.local 作為入口的的內(nèi)部請(qǐng)求才會(huì)激活 helloworld VirtualService 中的規(guī)則，該規(guī)則會(huì)將流量路由到 subset v1 。
要控制以 gateway host（例如myapp.com）作為入口的請(qǐng)求，還需要在 myapp VirtualService 中包括子集規(guī)則：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - "myapp.com" # or maybe "*" if you are testing without DNS using the ingress-gateway IP (e.g., http://1.2.3.4/hello)
  gateways:
  - myapp-gateway
  http:
  - match:
    - uri:
        prefix: /hello
    route:
    - destination:
        host: helloworld.default.svc.cluster.local
        subset: v1

或者將這兩個(gè) VirtualService 合并成一個(gè)：

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: myapp
spec:
  hosts:
  - myapp.com # cannot use "*" here since this is being combined with the mesh services
  - helloworld.default.svc.cluster.local
  gateways:
  - mesh # applies internally as well as externally
  - myapp-gateway
  http:
  - match:
    - uri:
        prefix: /hello
      gateways:
      - myapp-gateway #restricts this rule to apply only to ingress gateway
    route:
    - destination:
        host: helloworld.default.svc.cluster.local
        subset: v1
  - match:
    - gateways:
      - mesh # applies to all services inside the mesh
    route:
    - destination:
        host: helloworld.default.svc.cluster.local
        subset: v1

Envoy is crashing under load

檢查 ulimit -a 。 很多系統(tǒng)有默認(rèn)最多打開(kāi) 1024個(gè)fd(file descriptor) 的限制，這會(huì)導(dǎo)致 Envoy 的 assert失敗并crash，錯(cuò)誤信息如下:

[2017-05-17 03:00:52.735][14236][critical][assert] assert failure: fd_ != -1: external/envoy/source/common/network/connection_impl.cc:58

請(qǐng)確保提高了該限制，例如 ulimit -n 16384

Envoy無(wú)法連接到我的 HTTP/1.0 服務(wù)

Envoy需要upstream服務(wù)是 HTTP/1.1 或 HTTP/2 。
例如當(dāng)你使用Nginx作為上游服務(wù)的web server時(shí)，你需要設(shè)置nginx的 proxy_http_version 1.1 指令，因?yàn)閚ginx的該指令默認(rèn)值是 1.0
示例

upstream http_backend {
    server 127.0.0.1:8080;

    keepalive 16;
}

server {
    ...

    location /http/ {
        proxy_pass http://http_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        ...
    }
}

TLS配置錯(cuò)誤類(lèi)問(wèn)題

很多traffic管理問(wèn)題都是由不正確的 TLS配置 導(dǎo)致的。

發(fā)送HTTPS到HTTP端口

如果你將 HTTPS請(qǐng)求 發(fā)送到聲明為HTTP的服務(wù)，則 Envoy sidecar 將在轉(zhuǎn)發(fā)請(qǐng)求時(shí)嘗試將請(qǐng)求解析為HTTP，這將失敗，因?yàn)镠TTP意外地被加密。

例如你有如下的 ServiceEntry 定義:

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: httpbin
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 443
    name: http
    protocol: HTTP
  resolution: DNS

當(dāng)你發(fā)送 HTTPS請(qǐng)求，例如 curl https://httpbin.org , 你會(huì)得到一個(gè)錯(cuò)誤如下 curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
Envoy的 access log 會(huì)顯示一個(gè) 400 DPE 的錯(cuò)誤
這是因?yàn)槟銓?protocol 聲明成了 HTTP 而不是 HTTPS
要修復(fù)這個(gè)問(wèn)題，修改 ServiceEntry 定義如下:

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: httpbin
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS

Gateway to virtual service TLS mismatch

將 virtual service 綁定到 gateway 時(shí)，可能會(huì)發(fā)生兩種常見(jiàn)的TLS不匹配:

  • gateway terminate(終結(jié)了) TLS , 而 virtual service 配置了 TLS路由
  • gateway passthrough TLS ，而 virtual service 沒(méi)有配置 TLS路由

gateway終結(jié)了TLS而virtual service配置了TLS路由示例
假設(shè)你有如下的配置:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
      - "*"
    tls:
      mode: SIMPLE
      credentialName: sds-credential
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin
spec:
  hosts:
  - "*.example.com"
  gateways:
  - istio-system/gateway
  tls:
  - match:
    - sniHosts:
      - "*.example.com"
    route:
    - destination:
        host: httpbin.org

上面的這個(gè)配置， gateway 終結(jié)了TLS，而 virtual service 使用了基于TLS的路由規(guī)則， 這個(gè)路由規(guī)則不會(huì)生效 ，因?yàn)楫?dāng)路由規(guī)則被 evaluted(評(píng)估) 時(shí)，TLS已經(jīng)被終結(jié)。
使用這個(gè)配置，你會(huì)得到 404狀態(tài)碼 。
你可以通過(guò) istioctl proxy-config routes 命令來(lái)確認(rèn)這個(gè)信息

gateway passthrough TLS ，而 virtual service 沒(méi)有配置 TLS路由示例
假如你有如下的配置

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - hosts:
    - "*"
    port:
      name: https
      number: 443
      protocol: HTTPS
    tls:
      mode: PASSTHROUGH
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: virtual-service
spec:
  gateways:
  - gateway
  hosts:
  - httpbin.example.com
  http:
  - route:
    - destination:
        host: httpbin.org

上面的這個(gè)配置， gateway passthrough TLS，而 virtual service 沒(méi)有使用基于TLS的路由規(guī)則， 這個(gè)路由規(guī)則不會(huì)生效
你可以通過(guò) istioctl proxy-config listener 和 istioctl proxy-config routes 命令來(lái)確認(rèn)這個(gè)信息

Double TLS (TLS origination for a TLS request)

當(dāng)配置 Istio 執(zhí)行 TLS origination 時(shí)，你需要確保發(fā)送到 sidecar 的請(qǐng)求是純文本的， sidecar 隨后發(fā)起 TLS origination

假定你有如下的配置

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: httpbin
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 443
    name: https
    protocol: HTTPS
  resolution: DNS
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: originate-tls
spec:
  host: httpbin.org
  trafficPolicy:
    tls:
      mode: SIMPLE

使用此配置， Sidecar 希望應(yīng)用程序在端口443上發(fā)送TLS流量（例如 curl https://httpbin.org ），但它還將在轉(zhuǎn)發(fā)請(qǐng)求之前執(zhí)行 TLS origination 。 這將導(dǎo)致請(qǐng)求被雙重加密。
你會(huì)得到一個(gè)錯(cuò)誤 (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
要修復(fù)這個(gè)問(wèn)題，你可以將 ServiceEntry 中的 protocol 更改為 HTTP
然后用 curl http://httpbin.org:443 的方式發(fā)出請(qǐng)求
幸運(yùn)的是從 Istio 1.8 開(kāi)始，你可以向80端口發(fā)出請(qǐng)求，然后將請(qǐng)求重定向到 443以進(jìn)行TLS發(fā)起, 如下所示:

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: httpbin
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
    targetPort: 443

當(dāng)多個(gè)網(wǎng)關(guān)配置了相同的TLS證書(shū)時(shí)發(fā)生404錯(cuò)誤

使用相同的TLS證書(shū)配置多個(gè)網(wǎng)關(guān) 將導(dǎo)致利用 HTTP/2連接重用 的瀏覽器（即大多數(shù)瀏覽器） 在與一主機(jī)的建立連接之后 訪(fǎng)問(wèn)第二主機(jī)時(shí)產(chǎn)生 404錯(cuò)誤 。

假定你有如下配置:

  • 安裝在 istio-ingressgateway 中的通配符證書(shū) *.test.com
  • Gateway gw1 配置了 host = service1.test.com , selector = istio: ingressgateway , 并且使用網(wǎng)關(guān)已安裝的通配符證書(shū)的TLS
  • Gateway gw2 配置了 host = service2.test.com , selector = istio: ingressgateway , 并且使用網(wǎng)關(guān)已安裝的通配符證書(shū)的TLS
  • VirtualService vs1 綁定 gw1 和 host = service1.test.com
  • VirtualService vs2 綁定 gw2 和 host = service2.test.com

由于兩個(gè)網(wǎng)關(guān)由相同的工作負(fù)載（即 selector = istio: ingressgateway ）提供服務(wù)，因此對(duì)兩個(gè)服務(wù)（ service1.test.com 和 service2.test.com ）的請(qǐng)求都將解析為相同的IP。
如果首先訪(fǎng)問(wèn) service1.test.com ，它將返回通配符證書(shū)（ *.test.com ），指示與 service2.test.com 的連接可以使用同一證書(shū)。 因此，Chrome和Firefox等瀏覽器將重復(fù)使用現(xiàn)有連接來(lái)請(qǐng)求對(duì) service2.test.com 的請(qǐng)求。 由于 Gateway gw1 沒(méi)有 service2.test.com 的路由，因此它將返回 404響應(yīng) 。

要避免這個(gè)問(wèn)題，你可以配置一個(gè)單獨(dú)的 Gateway , 而不是兩個(gè)( gw1 和 gw2 ) 。就像下面這樣 :

  • Gateway gw 配置了 host = *.test.com , selector = istio: ingressgateway , 并且使用網(wǎng)關(guān)已安裝的通配符證書(shū)的TLS
  • VirtualService vs1 綁定 gw 和 host = service1.test.com
  • VirtualService vs2 綁定 gw 和 host = service2.test.com

在網(wǎng)關(guān)中配置多個(gè)TLS主機(jī)時(shí)端口沖突

當(dāng)使用相同的 selector 配置多個(gè) Gateway 時(shí)，如果它們都暴露了相同的 HTTPS 端口，你必須確保它們使用了不同的端口名稱(chēng)。否則后創(chuàng)建的Gateway會(huì)無(wú)效（ 雖然不會(huì)報(bào)錯(cuò) ）

加入你有如下配置:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: mygateway
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key
    hosts:
    - "myhost.com"
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: mygateway2
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
      privateKey: /etc/istio/ingressgateway-certs/tls.key
    hosts:
    - "myhost2.com"

使用這個(gè)配置，發(fā)送到 myhost2.com 的請(qǐng)求會(huì)失敗，因?yàn)閮蓚€(gè) Gateway 使用了相同的端口名稱(chēng) https ， curl 請(qǐng)求會(huì)產(chǎn)生如下的錯(cuò)誤:

curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to myhost2.com:443

你可以通過(guò)檢查 Pilot的日志來(lái)確認(rèn)發(fā)生了什么，如下所示：

$ kubectl logs -n istio-system $(kubectl get pod -l istio=pilot -n istio-system -o jsonpath={.items..metadata.name}) -c discovery | grep "non unique port"
2018-09-14T19:02:31.916960Z info    model   skipping server on gateway mygateway2 port https.443.HTTPS: non unique port name for HTTPS port

要避免這個(gè)問(wèn)題，可以將第二個(gè)gateway的端口名稱(chēng)修改（例如 https2 ）

安全方面的常見(jiàn)問(wèn)題

(TODO 待補(bǔ)充)
https://istio.io/latest/docs/ops/common-problems/security-issues/

可觀(guān)察性方面的常見(jiàn)問(wèn)題

Zipkin中沒(méi)有數(shù)據(jù)

Istio被安裝，并且所有的事情看起來(lái)都正常，除了Zipkin中沒(méi)有追蹤數(shù)據(jù)

這可能是由一個(gè)已知的Docker問(wèn)題引起的，就是容器內(nèi)部的時(shí)間可能與主機(jī)上的時(shí)間顯著不同。（這個(gè)問(wèn)題在 OSX 操作系統(tǒng)上出現(xiàn)）

你可以通過(guò)在容器內(nèi)部和外部執(zhí)行 date 命令來(lái)確認(rèn)。

要解決這個(gè)問(wèn)題，你需要關(guān)閉并重啟 Docker ，然后重新安裝 Istio

Grafana輸出丟失

同樣可能是時(shí)間的問(wèn)題
當(dāng)你從本地web客戶(hù)端連接到遠(yuǎn)端的Grafana時(shí)，如果你不能獲取Grafana的輸出，請(qǐng)確認(rèn)本地客戶(hù)端時(shí)間和服務(wù)端的時(shí)間是否相同
本地web客戶(hù)端(例如 Chrome)影響Grafana的輸出

驗(yàn)證Istio CNI Pod是否正在運(yùn)行（如果使用）

Istio CNI插件 在Kubernetes Pod生命周期的網(wǎng)絡(luò)設(shè)置階段執(zhí)行 Istio Mesh Pod流量重定向 ，從而消除了將Pod部署到Istio Mesh中的用戶(hù)對(duì) NET_ADMIN 和 NET_RAW 功能的要求。
Istio CNI插件 取代了 istio-init容器 提供的功能。

  1. 驗(yàn)證istio-cni-node容器是否正在運(yùn)行：
kubectl -n kube-system get pod -l k8s-app=istio-cni-node
  1. 如果在群集中強(qiáng)制執(zhí)行 PodSecurityPolicy ，請(qǐng)確保 istio-cni ServiceAccount 可以使用允許 NET_ADMIN 和 NET_RAW 功能的 PodSecurityPolicy 。

Sidecar注入方面的常見(jiàn)問(wèn)題

(TODO 待補(bǔ)充)
https://istio.io/latest/docs/ops/common-problems/injection/

配置驗(yàn)證方面的常見(jiàn)問(wèn)題

(TODO 待補(bǔ)充)
https://istio.io/latest/docs/ops/common-problems/validation/

診斷工具 - istioctl

獲取服務(wù)網(wǎng)格的overview信息

istioctl proxy-status
istioctl ps

如果輸出列表中缺少某個(gè)proxy，則表示該proxy當(dāng)前未連接到Pilot實(shí)例，因此不會(huì)接收任何配置。
此外，如果proxy被標(biāo)記為 stale(陳舊) ，則可能意味著存在網(wǎng)絡(luò)問(wèn)題或需要 擴(kuò)充Pilot實(shí)例的數(shù)量 。

獲取proxy的配置信息

istioctl proxy-config cluster <pod-name> [flags]
istioctl pc cluster <pod-name> [flags]

查閱pod信息

istioctl experimental describe pod <pod-name>[.<namespace>]
istioctl x describe pod <pod-name>[.<namespace>]

分析istio配置

istioctl analyze --all-namespaces

# 分析文件
istioctl analyze samples/bookinfo/networking/

Istiod Introspection(內(nèi)省、自我檢查)

Istiod 使用靈活的 Introspection（自?。┛蚣埽ǚQ(chēng)為 ControlZ ）構(gòu)建，這使得它很容易檢查和操作 istiod 實(shí)例 的內(nèi)部狀態(tài)。
Istiod 打開(kāi)一個(gè)web端口，可以通過(guò)瀏覽器使用交互視圖更改其狀態(tài)，或者通過(guò)REST API的方式。
當(dāng) istiod 啟動(dòng)時(shí)，通過(guò)它的日志信息可以看到連接到 ControlZ 的IP和端口
你可以通過(guò)在本地使用 istioctl dashboard 命令開(kāi)啟對(duì) Istio組件 的訪(fǎng)問(wèn)

istioctl dashboard controlz <istiod pod name> -n istio-system

然后打開(kāi)瀏覽器 http://localhost:9876

istio組件的日志

Istio組件使用靈活的日志框架構(gòu)建，該日志框架提供了許多功能和控件，以幫助操作這些組件并促進(jìn)診斷。
啟動(dòng)組件時(shí)，可以通過(guò)傳遞 命令行選項(xiàng) 來(lái)控制這些日志記錄功能。

1. Logging scopes

組件輸出的日志消息按 scopes 分類(lèi)。 scope 代表一組可以整體控制的相關(guān)日志消息。 根據(jù)組件提供的功能，不同的組件具有不同的 scopes 。 所有組件都有 default scope ，該scope用于未分類(lèi)的日志消息。

例如，在撰寫(xiě)本文時(shí)， istioctl 具有24個(gè) scope ，代表命令中的不同功能區(qū)域： ads, adsc, analysis, attributes, authn, authorization, cache, cli, default, grpcAdapter, installer, mcp, model, patch, processing, resource, secretfetcher, source, spiffe, tpath, translator, util, validation, validationController

Pilot-Agent，Pilot-Discovery和Istio Operator 具有它們自己的scopes，您可以通過(guò)查看它們的參考文檔來(lái)發(fā)現(xiàn)它們。

每個(gè)scope都有一個(gè)唯一的log level 為以下之一：
none error warning info debug

none 不產(chǎn)生任何輸出， debug 則產(chǎn)生最多的輸出
所有scopes的默認(rèn)level是 info

要控制輸出的level，可以使用 --log_output_level 命令行選項(xiàng)，如下所示：

istioctl analyze --log_output_level attributes:debug,cli:warn

2. 控制輸出位置

日志消息通常發(fā)送到組件的標(biāo)準(zhǔn)輸出流。 使用 --log_target 選項(xiàng)，您可以將輸出定向到任意數(shù)量的不同位置。 您可以為該選項(xiàng)提供一個(gè)用逗號(hào)分隔的文件系統(tǒng)路徑列表，以及特殊值 stdout和stderr ，分別表示標(biāo)準(zhǔn)輸出和標(biāo)準(zhǔn)錯(cuò)誤流。

日志消息通常以人類(lèi)友好的格式輸出。 --log_as_json 選項(xiàng)可用于將輸出強(qiáng)制轉(zhuǎn)換為JSON，這樣工具可以更輕松地進(jìn)行處理。

3. Log rotation

Istio控制平面組件 可以自動(dòng)管理 Log rotation ，這使將大型日志分解為較小的日志文件變得很簡(jiǎn)單。 使用 --log_rotate 選項(xiàng)，您可以指定用于rotation的基本文件名。 派生名稱(chēng)將用于單個(gè)日志文件。

使用 --log_rotate_max_age 選項(xiàng)可以指定文件rotation之前的最大天數(shù)，而使用 --log_rotate_max_size 選項(xiàng)可以指定文件rotation之前的最大大?。ㄒ詍egabytes為單位）。 最后， --log_rotate_max_backups 選項(xiàng)使您可以控制要保留的最大rotation文件數(shù)，較舊的文件將被自動(dòng)刪除。

3. 組件調(diào)試

使用 --log_caller 和 --log_stacktrace_level 選項(xiàng)，您可以控制日志信息是否包括 programmer-level 的信息。 當(dāng)試圖跟蹤組件中的bug時(shí)，這很有用，但通常在日常操作中不使用。

診斷工具 - pilot-discovery

該命令被 pilot 使用， pilot 是 istiod 的一部分，所以你可以在 istiod pod內(nèi)執(zhí)行該命令

kubectl exec -it istiod-76655fb8dd-8x7xk -c discovery -- bash

診斷工具 - operator

該命令被 istio-operator namespace中的 istio-operator deployment 使用，所以你可以在 istio-operator pod內(nèi)執(zhí)行該命令

kubectl exec -it -n istio-operator istio-operator-86d8595474-chkwf -- bash

診斷工具 - pilot-agent

該命令被注入的pod中的 istio-proxy container 使用，所以你可以在任意被注入的pod的 istio-proxy container 內(nèi)執(zhí)行該命令

kubectl exec -it <any injected pod> -c istio-proxy -- bash
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時(shí)請(qǐng)結(jié)合常識(shí)與多方信息審慎甄別。
平臺(tái)聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀(guān)點(diǎn)，簡(jiǎn)書(shū)系信息發(fā)布平臺(tái)，僅提供信息存儲(chǔ)服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

  • 服務(wù)網(wǎng)格（service mesh） 首先引入服務(wù)網(wǎng)格的概念，服務(wù)網(wǎng)格就是service mesh ，在很多年前就...
    chuan_bai閱讀 1,943評(píng)論 0贊 0
  • 首先，給大家簡(jiǎn)單介紹一下Istio，Istio是一個(gè)Service Mesh的開(kāi)源框架，來(lái)自Google，大部分使...
    碼道功臣閱讀 4,418評(píng)論 1贊 56
  • 王者的誕生：為什么Istio有如此高的呼聲？ 什么是 Istio？ 官方定義：它是一個(gè)完全開(kāi)源的服務(wù)網(wǎng)格，作為透明...
    端碗吹水閱讀 842評(píng)論 0贊 3
  • 久違的晴天，家長(zhǎng)會(huì)。 家長(zhǎng)大會(huì)開(kāi)好到教室時(shí)，離放學(xué)已經(jīng)沒(méi)多少時(shí)間了。班主任說(shuō)已經(jīng)安排了三個(gè)家長(zhǎng)分享經(jīng)驗(yàn)。 放學(xué)鈴聲...
    飄雪兒5閱讀 7,868評(píng)論 16贊 22
  • 今天感恩節(jié)哎，感謝一直在我身邊的親朋好友。感恩相遇！感恩不離不棄。 中午開(kāi)了第一次的黨會(huì)，身份的轉(zhuǎn)變要...
    余生動(dòng)聽(tīng)閱讀 10,918評(píng)論 0贊 11

友情鏈接更多精彩內(nèi)容