2. 程式人生 > >《Istio官方文件》Kubernetes-安裝Istio Sidecar

《Istio官方文件》Kubernetes-安裝Istio Sidecar

阿新 • • 發佈：2018-12-23

安裝Istio Sidecar

注：以下要求Istio 0.5.0或更高版本。有關版本0.4.0或更高版本，請參閱https://archive.istio.io/v0.4/docs/setup/kubernetes/sidecar-injection。

注意：在以前的版本中，Kubernetes初始化程式功能已用於自動代理注入。這是一個可以更改/刪除的alpha功能，並且在Kubernetes中預設不啟用。從Istio 0.5.0釋出開始，自動代理注入使用Kubernetes突變webhooks。這個Kubernetes功能是用來測試且預設情況下在Kubernetes 1.9及以上會獲得到。在0.5.0中已經刪除了對代理注入的alpha初始值設定機制的支援。無法升級到Kubernetes 1.9的使用者應使用手動注入。

Pod規格要求

為了成為服務網格的一部分，kubernetes叢集中的每個容器必須滿足以下要求：

  1. 服務關聯：該窗格必須屬於單個 （截至目前，不支援屬於多個服務的窗格）。
  2. 命名埠：服務埠必須命名。埠名稱必須是<protocol>[-<suffix>] <protocol>這種形式，且與http, http2, grpc, mongo, or redis 相搭配，以便充分利用Istio的路由功能。例如，name: http2-foo或者name: http是有效的埠名稱，但name: http2foo不是。如果埠名稱不是以可識別的字首開頭，或者埠未命名，則埠上的通訊將被視為純TCP通訊（除非埠明確用於Protocol: UDP表示UDP埠）。
  3. 具有應用標籤的部署：建議使用Kubernetes deployment部署的Pod在部署規範中具有顯式app標籤。每個部署規範都應該有一個明確的app標籤，其中這個標籤具有一個有意義的值。該app標籤用於在分散式跟蹤中新增上下文資訊。
  4. 網格中的每個pod Sidecar：最後，網格中的每個pod必須執行與Istio相容的sidecar。以下部分介紹了將Istio sidecar注入到一個pod的兩種方法：手動使用istioctl CLI工具或自動使用Istio初始化程式。請注意，sidecar不涉及同一pod內的容器之間的通訊。

注入

手動注入可以修改控制器配置，例如部署。這是通過修改pod模板規範來完成的，這樣所有用於該部署的pod都是用注入的sidecar建立的。新增/更新/刪除sidecar需要修改整個部署。

在建立時間點自動注入。控制器資源未修改。可以通過手動刪除pods或通過部署滾動更新系統地選擇更新sidecars。

手動和自動注入使用相同的模板化配置。自動注入從istio-system名稱空間中的istio-inject ConfigMap 載入配置。手動注入可以從本地檔案或ConfigMap中載入。

注入配置的兩種變型提供了預設的安裝：istio-sidecar-injector-configmap-release.yaml和istio-sidecar-injector-configmap-debug.yaml。注入配置對映包括預設的注入策略和sidecar注入模板。除錯版本包括除錯代理映像以及用於除錯sidecar代理的附加日誌記錄和核心轉儲功能。

手動sidecar注射

使用內建的預設模板，並從istio ConfigMap中動態獲取網格配置。其他引數覆蓋可通過標誌（請參閱istioctl kube-inject –help）。

kubectl apply -f <(~istioctl kube-inject -f samples/sleep/sleep.yaml)

kube-inject也可以在不訪問正在執行的Kubernetes叢集的情況下執行。建立注入和網格配置圖的本地副本。

kubectl create -f install/kubernetes/istio-sidecar-injector-configmap-release.yaml \
    --dry-run \
    -o=jsonpath='{.data.config}' > inject-config.yaml

kubectl -n istio-system get configmap istio -o=jsonpath='{.data.mesh}' > mesh-config.yaml

Run kube-inject`在輸入檔案上。

istioctl kube-inject \
    --injectConfigFile inject-config.yaml \
    --meshConfigFile mesh-config.yaml \
    --filename samples/sleep/sleep.yaml \
    --output sleep-injected.yaml

部署注入的YAML檔案。

kubectl apply -f sleep-injected.yaml

確認sidecar已經注入到部署中。

kubectl get deployment sleep -o wide

NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       CONTAINERS          IMAGES                             SELECTOR
sleep     1         1         1            1           2h        sleep,istio-proxy   tutum/curl,unknown/proxy:unknown   app=sleep

自動sidecar注入

先決條件

Kubernetes 1.9叢集需要啟用admissionregistration.k8s.io/v1beta1。

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

GKE

1.9.1適用於具有alpha群集的非白名單早期訪問使用者（請參閱https://cloud.google.com/kubernetes-engine/release-notes#january-16-2018）。

gcloud container clusters create <cluster-name> \
    --enable-kubernetes-alpha 
    --cluster-version=1.9.1-gke.0 
    --zone=<zone>
    --project <project-name>

gcloud container clusters get-credentials <cluster-name> \
    --zone <zone> \
    --project <project-name>

kubectl create clusterrolebinding cluster-admin-binding \
    --clusterrole=cluster-admin \
    --user=$(gcloud config get-value core/account)

minikube

TODO（https://github.com/istio/istio.github.io/issues/885）

IBM雲容器服務

TODO（https://github.com/istio/istio.github.io/issues/887）

AWS與Kops

TODO（https://github.com/istio/istio.github.io/issues/886）

安裝Webhook

安裝基地Istio。

kubectl apply -f install/kubernetes/istio.yaml

Webhooks需要一個簽名的證書/金鑰對。使用install/kubernetes/webhook-create-signed-cert.sh來產生由Kubernetes’ CA簽名的證書/金鑰對，生成的證書/金鑰檔案作為Kubernetes 私密儲存，以便sidecar注入器webhook使用。

注意：Kubernetes CA批准需要建立和批准CSR的許可權。請參閱https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster並install/kubernetes/webhook-create-signed-cert.sh獲取更多資訊。

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

安裝sidecar注入配置圖。

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

在webhook中設定caBundle安裝YAML的Kubernetes API伺服器用來呼叫webhook。

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

安裝sidecar注入webhook。

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

sidecar注入webhook現在應該執行。

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（請參閱https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors） 。預設的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

部署一個應用程式

部署睡眠應用程式。驗證部署和Pod都有一個容器。

kubectl apply -f samples/sleep/sleep.yaml
kubectl get deployment -o wide

NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE       CONTAINERS   IMAGES       SELECTOR
sleep     1         1         1            1           12m       sleep        tutum/curl   app=sleep
kubectl get pod

NAME                     READY     STATUS        RESTARTS   AGE
sleep-776b7bcdcd-7hpnk   1/1       Running       0          4

用istio-injection=enabled標註default名稱空間

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

注入發生在建立時間點。殺死執行pod，並驗證一個新的pod與注入sidecar建立。原來的pod有1/1的READY容器，而注入sidecar的pod有2/2的READY容器。

kubectl delete pod sleep-776b7bcdcd-7hpnk 
kubectl get pod

NAME                     READY     STATUS        RESTARTS   AGE
sleep-776b7bcdcd-7hpnk   1/1       Terminating   0          1m
sleep-776b7bcdcd-bhn9m   2/2       Running       0          7s

禁用default名稱空間的注入，並驗證新的pods沒有用sidecar來建立。

kubectl label namespace default istio-injection-
kubectl delete pod sleep-776b7bcdcd-bhn9m
kubectl get pod

NAME                     READY     STATUS        RESTARTS   AGE
sleep-776b7bcdcd-bhn9m   2/2       Terminating   0          2m
sleep-776b7bcdcd-gmvnr   1/1       Running       0          2s

瞭解發生了什麼

配置何時Kubernetes呼叫webhook。Istio提供的預設選擇pods在名稱空間中用標籤istio-injection=enabled來配置。這可以通過修改install/kubernetes/istio-sidecar-injector-with-ca-bundle.yaml中的MutatingWebhookConfiguration來改變。

在 istio-system名稱空間中將istio-inject ConfigMap配置預設注入政策和sidecar注入模板。

政策

disabled -sidecar注入器預設不會將sidecar注入到pods。將sidecar.istio.io/inject註釋值設定為true到pod模板規範以啟用注入。

enabled -sidecar注入器預設將sidecar注入到pods。將sidecar.istio.io/inject註釋值設定為false到pod模板規範以禁用注入。

模板

sidecar注入模板使用https://golang.org/pkg/text/template，在解析和執行時，解碼為包含要注入到pod中的容器和容器列表的以下結構。

   type SidecarInjectionSpec struct {
          InitContainers []v1.Container `yaml:"initContainers"`
          Containers     []v1.Container `yaml:"containers"`
          Volumes        []v1.Volume    `yaml:"volumes"`
    }

該模板在執行時應用於以下資料結構。

type SidecarTemplateData struct {
    ObjectMeta  *metav1.ObjectMeta        
    Spec        *v1.PodSpec               
    ProxyConfig *meshconfig.ProxyConfig  // Defined by https://istio.io/docs/reference/config/service-mesh.html#proxyconfig
    MeshConfig  *meshconfig.MeshConfig   // Defined by https://istio.io/docs/reference/config/service-mesh.html#meshconfig 
}

ObjectMeta 和Spec來自pod。ProxyConfig 和MeshConfig來自istio-system名稱空間中的istio ConfigMap 。模板可以使用此資料有條件地定義注入的容器和容量。

例如，以下來自install / kubernetes / istio-sidecar-injector-configmap-release.yaml的模板片段

containers:
- name: istio-proxy
  image: istio.io/proxy:0.5.0
  args:
  - proxy
  - sidecar
  - --configPath
  - {{ .ProxyConfig.ConfigPath }}
  - --binaryPath
  - {{ .ProxyConfig.BinaryPath }}
  - --serviceCluster
  {{ if ne "" (index .ObjectMeta.Labels "app") -}}
  - {{ index .ObjectMeta.Labels "app" }}
  {{ else -}}
  - "istio-proxy"
  {{ end -}}

當應用在sample/sleep/sleep.yaml中由pod模板規範定義的pod上時，需要如下擴充套件：

containers:
- name: istio-proxy
  image: istio.io/proxy:0.5.0
  args:
  - proxy
  - sidecar
  - --configPath
  - /etc/istio/proxy
  - --binaryPath
  - /usr/local/bin/envoy
  - --serviceCluster
  - sleep

解除安裝webhook

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

上面的命令不會從Pod中刪除注入的sidecars。滾動更新或簡單地刪除pods並強制部署來建立它們是必需的。


相關推薦

《Istio官方文件》Kubernetes-安裝Istio Sidecar

安裝Istio Sidecar 注：以下要求Istio 0.5.0或更高版本。有關版本0.4.0或更高版本，請參閱https://archive.istio.io/v0.4/docs/setup/kubernetes/sidecar-injection。 注意：在以前的版本中，Kubernet

《Istio官方文件》Eureka-安裝

安裝 在非Kubernetes環境中使用Istio涉及如下關鍵任務： 使用Istio API伺服器設定Istio控制平面 將Istio邊車新增到服務的每個例項 確保請求通過sidecars路由 設定控制面 Istio控制平面由四個主要服務組成：Pilot，Mixer，CA和API伺服器。

《Istio官方文件》Nomad & Consul-安裝

安裝 注意：Nomad上的設定尚未經過測試。 在非Kubernetes環境中使用Istio涉及以下關鍵任務： 使用Istio API伺服器設定Istio控制平面 將Istio sidecar新增到服務的每個例項 確保請求通過sidecars路由 設定控制面 Istio控制平面由四個主要服務

《Istio官方文件》Google Kubernetes引擎快速入門

Google Kubernetes引擎快速入門 這種快速啟動用來建立一個新的GKE叢集，安裝Istio然後部署示例應用程式。它使用Deployment Manager自動執行，在詳細介紹。 注：預設安裝將建立一個GKE ，允許。由於它是一個alpha群集，它不支援自動節點或主升級，將在30天

《Istio官方文件》Kubernetes-Istio網格擴充套件

Istio網格擴充套件 將虛擬機器和裸機主機整合到部署在Kubernetes上的Istio網格中的說明如下。 先決條件 按照安裝指南中的說明在Kubernetes上安裝Istio 。 機器必須具有到網格中節點的IP連線。這通常需要一個VPC或一個VPN，以及一個提供直接（沒有NAT或防火牆拒

《Istio官方文件》Kubernetes快速開始

Kubernetes快速開始 在Kubernetes群集中安裝和配置Istio時，可以參考如下快速入門說明。 先決條件 以下說明要求您有權訪問啟用了RBAC（基於角色的訪問控制）的Kubernetes 1.7.3或更新的群集。你還需要安裝1.7.3或更新版本。如果您希望啟用自動注射支架，您需要

《Istio官方文件》翻譯邀請

2018新年快樂，本月併發網組織翻譯Service Mesh框架(什麼是Service Mesh)《Istio官方文件》，歡迎有興趣的同學參與。 如何領取 通過評論領取想要翻譯的文章，每次領取一章或一節（根據內容長短），翻譯完後再領取其他章節。領取完成之後，建議在一個星期內翻譯完成，如果不能

《Istio官方文件》—— 錯誤注入

原文連結  譯者:carvendy   當使者邊車/代理提供了一大堆故障恢復機制讓服務在Istio上執行，這依然有必要去測試端對端的故障恢復作為了應用的整體功能。錯誤配置的故障策略(例如：矛盾的或者服務響應的超時限制)會讓在程式中的服務界定為不可用，影響到我們希望的結果。   Istio可以指

《Istio官方文件》流量管理–綜述

原文連結  譯者:carvendy 綜述   本頁提供在Istio中，如何管理流量，包括流量管理原則的好處。假設你已經讀了什麼是Istio?,並且熟悉與Istio相關的高可用架構。你可以本章節的其他指南中，找到個別的流量管理特性。 領航員（Pilot）和使者（Envoy）   在Istio中

《Istio官方文件》—— 服務發現與負載均衡

原文連結  譯者:carvendy 服務發現與負載均衡   本文講述Istio在服務網格中，如何對互動的服務進行負載均衡。   服務註冊: Istio假定存在一個服務可以將pod/VM的地址資訊註冊上去。假設一個新的服務可以自動註冊上去，而當服務不健康的時候可以自動移除。管理平臺，比如說Kub

《Istio官方文件》—— 故障處理

原文連結  譯者:carvendy 故障處理    使者在故障恢復中，提供了一個拆箱即用的集合，可以更方便地在服務中移除應用。特性包括： 超時 限定的重試，在重試之間有超時預計與數值的波動性。 有限的併發連線數和請求的上游服務。 對於負載均衡池裡的成員，進行動態（週期性的）健康檢查。 細粒度

《Istio官方文件》—— 請求路由

原文連結  譯者:carvendy 請求路由   本頁描述，在Istio服務網格中，服務間的請求是如何被路由的。 服務模型和服務版本   領航員的職責是，在原始網格中維護的權威服務。Istio的服務模型是如何依賴底層的平臺（Kubernetes、 Mesos、Cloud Foundry等）。

《Istio官方文件》什麼是Istio——設計理念

原文連結  譯者:carvendy 設計理念   這頁概述了Istio的核心設計理念。   Istio的架構裡有一些關鍵的設計理念，是在服務在一定規模上和高效能的標準上，系統必備的能力。 公開透明。為了適應Istio，運維人員和開發人員應該做一些最小限度的工作從系統中獲取真實值。為此，Ist

《Istio官方文件》Pilot

原文連結  譯者:carvendy Pilot(領航員)   Pilot負責Envoy例項在Istio網格服務部署的生命週期。    在上圖中的圖形，Pilot在服務網格中有著權威的服務代表，而服務網格依賴著底層平臺。在Pilot中的特定平臺介面卡負責適當地構成權威模型。作為例子，在Pilot

《Istio官方文件》Nomad & Consul-Docker快速入門

Docker快速入門 以下為在Docker Compose安裝程式中安裝和配置Istio的快速入門說明。 先決條件 安裝步驟 轉至頁面下載與您的作業系統相對應的安裝檔案。如果您使用的是MacOS或Linux系統，則還可以執行以下命令自動下載並提取最新版本： curl -L https:

《Istio官方文件》Eureka-Docker快速入門

Docker快速入門 以下為在Docker Compose安裝程式中安裝和配置Istio的快速入門說明。 先決條件 安裝步驟 轉至頁面下載與您的作業系統相對應的安裝檔案。如果您使用的是MacOS或Linux系統，則還可以執行以下命令自動下載並提取最新版本： curl -L https:

《Linkerd官方文件》與Istio一起執行Linkerd

與Istio一起執行 Istio是一個連線，管理和保護微服務的開放平臺。Linkerd是雲本機應用程式的開源服務網格。Istio和Linkerd可以一起工作，Istio可作為跨Linkerd例項的控制平面。 Linkerd的Istio整合是實驗性的，目前支援 路由規則， 入口， 出口和 指標。

《Istio官方文件》什麼是Istio——綜述

原文連結  譯者：carvendy 綜述   本文介紹Istio：開源的連線，管理和安全的微服務。Istio提供了一種簡單方式，讓釋出的服務建立連線並實現負載均衡，服務間的認證，監控，還有更多，而在服務中不需要改變任何程式碼。接入Istio，支援服務由特定的代理髮布，在服務之間會攔截網路通訊並

《Istio官方文件》配置請求路由

原文連結 譯者:suzhuo 配置請求路由 這裡將向你展示如何根據權重和HTTP請求頭去配置動態路由。 “開始之前” 注意:這裡假設你正在Kubernetes上部署應用.所有例子的命令都使用yaml規則檔案的Kubernetes版本(例如:”samples/bookinfo/kube/ro

第三天 docker 官方文件學習安裝

Docker 安裝 目前Docker 有2個版本一個是docker-ce 和docker-ee: Docker Engine改為Docker CE（社群版） Docker Data Center改為Docker EE（企業版） Docker CE 和Docker EE。Docker CE