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

可觀察性

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

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)開始, Envoy自身也有很豐富的metrics統(tǒng)計(jì)信息签舞。這被稱為 Proxy-level metrics
除了 Proxy-level metrics , Istio 還提供了一組 面向服務(wù) 的metrics秕脓，就是上述的 latency(延遲) 柒瓣、 traffic(流量) 、 errors 吠架、 saturation(飽和度) 芙贫。這被稱為 Service-level metrics
啟用 Service-level metrics 是可選的，運(yùn)維人員可以選擇關(guān)閉這些指標(biāo)的生成和收集傍药，以滿足他們的個(gè)性化需求磺平。

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

在 IstioOperator CR 中增加如下配置：

spec:
  meshConfig:
    accessLogFile: /dev/stdout

流量管理方面的常見問題

Requests被Envoy拒絕

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

kubectl logs PODNAME -c istio-proxy -n NAMESPACE

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

常見的 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的值不能是 - ）

常見的 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ī)則似乎沒有影響traffic flow

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

另一個(gè)潛在的可能是路線規(guī)則的生效速度有些緩慢炬太。 Kubernetes上的 Istio實(shí)現(xiàn) 使用 最終一致的算法 來確保所有Envoy sidecar具有一致的配置，包括所有路由規(guī)則驯耻。配置更改將需要一些時(shí)間才能傳播到所有 sidecars亲族。在大型部署中，傳播將花費(fèi)更長的時(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)致客戶端的 proxy sidecar 發(fā)出純HTTP請(qǐng)求而不是TLS加密請(qǐng)求。因?yàn)榉?wù)端的 proxy sidecar 期望加密的請(qǐng)求筒扒，所以客戶端代理發(fā)出的請(qǐng)求與服務(wù)端代理期望接受的請(qǐng)求發(fā)生沖突怯邪。

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

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

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

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ì)注意到和泌，通過入口網(wǎng)關(guān)向helloworld服務(wù)的請(qǐng)求將不會(huì)定向到子集v1，而是將繼續(xù)使用默認(rèn)的 round-robin routing(輪詢路由) 祠肥。
以 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)最多打開 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無法連接到我的 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ò)誤類問題

很多traffic管理問題都是由不正確的 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è)問題，修改 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ā)生兩種常見的TLS不匹配:

gateway terminate(終結(jié)了) TLS , 而 virtual service 配置了 TLS路由
gateway passthrough TLS 犯眠，而 virtual service 沒有配置 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)碼 。
你可以通過 istioctl proxy-config routes 命令來確認(rèn)這個(gè)信息

gateway passthrough TLS 危融，而 virtual service 沒有配置 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 沒有使用基于TLS的路由規(guī)則吉殃， 這個(gè)路由規(guī)則不會(huì)生效
你可以通過 istioctl proxy-config listener 和 istioctl proxy-config routes 命令來確認(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è)問題贼陶，你可以將 ServiceEntry 中的 protocol 更改為 HTTP
然后用 curl http://httpbin.org:443 的方式發(fā)出請(qǐng)求
幸運(yùn)的是從 Istio 1.8 開始，你可以向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í)發(fā)生404錯(cuò)誤

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

假定你有如下配置:

安裝在 istio-ingressgateway 中的通配符證書 *.test.com
Gateway gw1 配置了 host = service1.test.com , selector = istio: ingressgateway , 并且使用網(wǎng)關(guān)已安裝的通配符證書的TLS
Gateway gw2 配置了 host = service2.test.com , selector = istio: ingressgateway , 并且使用網(wǎng)關(guān)已安裝的通配符證書的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禁添。
如果首先訪問 service1.test.com 撮胧，它將返回通配符證書（ *.test.com ），指示與 service2.test.com 的連接可以使用同一證書老翘。因此芹啥，Chrome和Firefox等瀏覽器將重復(fù)使用現(xiàn)有連接來請(qǐng)求對(duì) service2.test.com 的請(qǐng)求。由于 Gateway gw1 沒有 service2.test.com 的路由铺峭，因此它將返回 404響應(yīng) 墓怀。

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

Gateway gw 配置了 host = *.test.com , selector = istio: ingressgateway , 并且使用網(wǎng)關(guān)已安裝的通配符證書的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 端口，你必須確保它們使用了不同的端口名稱莉炉。否則后創(chuàng)建的Gateway會(huì)無效（ 雖然不會(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 使用了相同的端口名稱 https 呢袱， curl 請(qǐng)求會(huì)產(chǎn)生如下的錯(cuò)誤:

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

你可以通過檢查 Pilot的日志來確認(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è)問題，可以將第二個(gè)gateway的端口名稱修改（例如 https2 ）

安全方面的常見問題

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

可觀察性方面的常見問題

Zipkin中沒有數(shù)據(jù)

Istio被安裝羞福，并且所有的事情看起來都正常惕蹄，除了Zipkin中沒有追蹤數(shù)據(jù)

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

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

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

Grafana輸出丟失

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

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

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

驗(yàn)證istio-cni-node容器是否正在運(yùn)行：

kubectl -n kube-system get pod -l k8s-app=istio-cni-node

如果在群集中強(qiáng)制執(zhí)行 PodSecurityPolicy 餐曹，請(qǐng)確保 istio-cni ServiceAccount 可以使用允許 NET_ADMIN 和 NET_RAW 功能的 PodSecurityPolicy 逛拱。

Sidecar注入方面的常見問題

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

配置驗(yà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ò)問題或需要擴(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（自噬薪尽）框架（稱為 ControlZ ）構(gòu)建轧坎，這使得它很容易檢查和操作 istiod 實(shí)例 的內(nèi)部狀態(tài)宏邮。
Istiod 打開一個(gè)web端口，可以通過瀏覽器使用交互視圖更改其狀態(tài)，或者通過REST API的方式蜜氨。
當(dāng) istiod 啟動(dòng)時(shí)械筛，通過它的日志信息可以看到連接到 ControlZ 的IP和端口
你可以通過在本地使用 istioctl dashboard 命令開啟對(duì) Istio組件 的訪問

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

然后打開瀏覽器 http://localhost:9876

istio組件的日志

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

1. Logging scopes

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

例如爷辱，在撰寫本文時(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，您可以通過查看它們的參考文檔來發(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ò)誤流浸踩。

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

3. Log rotation

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

使用 --log_rotate_max_age 選項(xiàng)可以指定文件rotation之前的最大天數(shù)怕犁，而使用 --log_rotate_max_size 選項(xiàng)可以指定文件rotation之前的最大大斜呃骸（以megabytes為單位）开睡。最后， --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

最后編輯于：2021.03.31 16:26:20

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請(qǐng)聯(lián)系作者

人面猴
序言：七十年代末，一起剝皮案震驚了整個(gè)濱河市漆撞，隨后出現(xiàn)的幾起案子殴泰，更是在濱河造成了極大的恐慌，老刑警劉巖浮驳，帶你破解...
沈念sama閱讀 207,113評(píng)論 6贊 481
死咒
序言：濱河連續(xù)發(fā)生了三起死亡事件悍汛，死亡現(xiàn)場離奇詭異，居然都是意外死亡至会，警方通過查閱死者的電腦和手機(jī)离咐，發(fā)現(xiàn)死者居然都...
沈念sama閱讀 88,644評(píng)論 2贊 381
救了他兩次的神仙讓他今天三更去死
文/潘曉璐我一進(jìn)店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來奉件，“玉大人宵蛀，你說我怎么就攤上這事∠孛玻” “怎么了术陶？”我有些...
開封第一講書人閱讀 153,340評(píng)論 0贊 344
道士緝兇錄：失蹤的賣姜人
文/不壞的土叔我叫張陵，是天一觀的道長窃这。經(jīng)常有香客問我瞳别，道長征候，這世上最難降的妖魔是什么杭攻？我笑而不...
開封第一講書人閱讀 55,449評(píng)論 1贊 279
?港島之戀（遺憾婚禮）
正文為了忘掉前任，我火速辦了婚禮疤坝，結(jié)果婚禮上兆解，老公的妹妹穿的比我還像新娘。我一直安慰自己跑揉，他們只是感情好锅睛，可當(dāng)我...
茶點(diǎn)故事閱讀 64,445評(píng)論 5贊 374
惡毒庶女頂嫁案：這布局不是一般人想出來的
文/花漫我一把揭開白布埠巨。她就那樣靜靜地躺著，像睡著了一般现拒。火紅的嫁衣襯著肌膚如雪。梳的紋絲不亂的頭發(fā)上，一...
開封第一講書人閱讀 49,166評(píng)論 1贊 284
城市分裂傳說
那天泣特，我揣著相機(jī)與錄音基显，去河邊找鬼。笑死侥猬，一個(gè)胖子當(dāng)著我的面吹牛例驹，可吹牛的內(nèi)容都是我干的。我是一名探鬼主播退唠，決...
沈念sama閱讀 38,442評(píng)論 3贊 401
雙鴛鴦連環(huán)套：你想象不到人心有多黑
文/蒼蘭香墨我猛地睜開眼鹃锈，長吁一口氣：“原來是場噩夢(mèng)啊……” “哼！你這毒婦竟也來了瞧预？” 一聲冷哼從身側(cè)響起屎债，我...
開封第一講書人閱讀 37,105評(píng)論 0贊 261
萬榮殺人案實(shí)錄
序言：老撾萬榮一對(duì)情侶失蹤，失蹤者是張志新（化名）和其女友劉穎垢油，沒想到半個(gè)月后扔茅，有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體，經(jīng)...
沈念sama閱讀 43,601評(píng)論 1贊 300
?護(hù)林員之死
正文獨(dú)居荒郊野嶺守林人離奇死亡秸苗，尸身上長有42處帶血的膿包…… 初始之章·張勛以下內(nèi)容為張勛視角年9月15日...
茶點(diǎn)故事閱讀 36,066評(píng)論 2贊 325
?白月光啟示錄
正文我和宋清朗相戀三年召娜，在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片惊楼。...
茶點(diǎn)故事閱讀 38,161評(píng)論 1贊 334
活死人
序言：一個(gè)原本活蹦亂跳的男人離奇死亡玖瘸，死狀恐怖，靈堂內(nèi)的尸體忽然破棺而出檀咙，到底是詐尸還是另有隱情雅倒，我是刑警寧澤，帶...
沈念sama閱讀 33,792評(píng)論 4贊 323
?日本核電站爆炸內(nèi)幕
正文年R本政府宣布弧可，位于F島的核電站蔑匣，受9級(jí)特大地震影響，放射性物質(zhì)發(fā)生泄漏棕诵。R本人自食惡果不足惜裁良，卻給世界環(huán)境...
茶點(diǎn)故事閱讀 39,351評(píng)論 3贊 307
男人毒藥：我在死后第九天來索命
文/蒙蒙一、第九天我趴在偏房一處隱蔽的房頂上張望校套。院中可真熱鬧价脾，春花似錦、人聲如沸笛匙。這莊子的主人今日做“春日...
開封第一講書人閱讀 30,352評(píng)論 0贊 19
一樁弒父案犀变，背后竟有這般陰謀
文/蒼蘭香墨我抬頭看了看天上的太陽。三九已至秋柄，卻和暖如春获枝，著一層夾襖步出監(jiān)牢的瞬間，已是汗流浹背骇笔。一陣腳步聲響...
開封第一講書人閱讀 31,584評(píng)論 1贊 261
情欲美人皮
我被黑心中介騙來泰國打工映琳，沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留，地道東北人蜘拉。一個(gè)月前我還...
沈念sama閱讀 45,618評(píng)論 2贊 355
代替公主和親
正文我出身青樓萨西，卻偏偏與公主長得像，于是被迫代替她去往敵國和親旭旭。傳聞我的和親對(duì)象是個(gè)殘疾皇子谎脯，可洞房花燭夜當(dāng)晚...
茶點(diǎn)故事閱讀 42,916評(píng)論 2贊 344