🥇Przygotowanie aplikacji do Istio

Istio to wygodne narzędzie do łączenia, zabezpieczania i monitorowania rozproszonych aplikacji. Istio wykorzystuje różne technologie do masowego uruchamiania oprogramowania i zarządzania nim, w tym kontenery do pakowania kodu aplikacji i zależności do wdrożenia oraz Kubernetes do zarządzania tymi kontenerami. Dlatego aby pracować z Istio, musisz wiedzieć, jak działa aplikacja oparta na tych technologiach, składająca się z wielu usług. bez Istio. Jeśli te narzędzia i pojęcia są Ci już znane, możesz śmiało pominąć ten przewodnik i przejść bezpośrednio do sekcji. Instalacja Istio na Google Kubernetes Engine (GKE) lub instalacja rozszerzenia. Istio na GKE.

To przewodnik krok po kroku, w którym omówimy cały proces od kodu źródłowego do kontenera na GKE, abyś miał podstawowe zrozumienie tych technologii na przykładzie. Zobaczysz również, jak Istio wykorzystuje możliwości tych technologii. Zakłada się, że nie wiesz nic o kontenerach, Kubernetes, service mesh ani Istio.

Zadania

W tym przewodniku wykonasz następujące zadania:

Zbadanie prostego aplikacji hello world z wieloma usługami.
Uruchomienie aplikacji z kodu źródłowego.
Pakowanie aplikacji w kontenery.
Utworzenie klastra Kubernetes.
Wdrożenie kontenerów w klastrze.

Zanim zaczniesz

Postępuj zgodnie z instrukcjami, aby włączyć API Google Kubernetes Engine:

Przejdź do strony Kubernetes Engine w konsoli Google Cloud Platform.
Utwórz lub wybierz projekt.
Poczekaj, aż API i związane usługi zostaną włączone. To może zająć kilka minut.
Upewnij się, że wystawianie faktur dla projektu Google Cloud Platform jest włączone. Dowiedz się, jak włączyć wystawianie faktur..

W tym przewodniku możesz używać Cloud Shell, który przygotowuje maszynę wirtualną g1-small w Google Compute Engine z systemem Linux opartym na Debianie, lub komputera z systemem Linux lub macOS.

Opcja A: korzystanie z Cloud Shell

Zalety korzystania z Cloud Shell:

Środowiska programistyczne Python 2 i Python 3 (w tym virtualenv) są w pełni skonfigurowane.
Narzędzia wiersza poleceń gcloud, docker, sshpass i kubectl, które będziemy używać, są już zainstalowane.
Masz do wyboru kilka edytorów tekstu.:
1. Edytor kodu, który otwiera się ikoną edytowania w górnej części okna Cloud Shell.
2. Emacs, Vim lub Nano, które otwierają się z linii poleceń w Cloud Shell.

Aby korzystać z Cloud Shell:

Przejdź do konsoli GCP.
Naciśnij przycisk Aktywuj Cloud Shell (Aktywować Cloud Shell) w górnej części okna konsoli GCP.

Na dole konsoli GCP otworzy się nowa sesja Cloud Shell z wierszem polecenia.

Opcja B: używanie narzędzi wiersza poleceń lokalnie

Jeśli pracujesz na komputerze z Linuxem lub macOS, musisz skonfigurować i zainstalować następujące komponenty:

Skonfiguruj środowisko programistyczne Python 3 i Python 2.
Zainstaluj Cloud SDK z narzędziem wiersza poleceń gcloud.
Zainstaluj kubectl — narzędzie wiersza poleceń do pracy z Kubernetes.
```
gcloud components install kubectl
```
Zainstaluj Docker Community Edition (CE). Będziesz używać narzędzia wiersza poleceń docker, aby tworzyć obrazy kontenerów dla przykładu aplikacji.
Zainstaluj narzędzie systemu kontroli wersji Git, aby pobrać przykład aplikacji z GitHub.

Pobieranie przykładu kodu

Pobierz kod źródłowy helloserver:

git clone https://github.com/GoogleCloudPlatform/istio-samples

Przejdź do katalogu przykładu kodu:

cd istio-samples/sample-apps/helloserver

Badanie aplikacji z wieloma serwisami

Przykład aplikacji napisany jest w Pythonie i składa się z dwóch komponentów, które współdziałają za pomocą REST:

server: prosty serwer z jedną końcówką GET, /, który wyświetla "hello world" na konsoli.
loadgen: skrypt, który wysyła ruch do server, z konfigurowalną liczbą zapytań na sekundę.

Uruchamianie aplikacji z kodu źródłowego

Aby zbadać przykład aplikacji, uruchom go w Cloud Shell lub na komputerze.
1) W katalogu istio-samples/sample-apps/helloserver uruchom server:

python3 server/server.py

Po uruchomieniu server wyświetli się następujące:

INFO:root:Rozpoczynanie serwera...

2) Otwórz inne okno terminala, aby wysyłać zapytania do server. Jeśli używasz Cloud Shell, kliknij ikonę dodawania, aby otworzyć inną sesję.
3) Wyślij zapytanie do server:

curl http://localhost:8080

serwer odpowiada:

Hello World!

4) Z katalogu, w którym pobrałeś przykład kodu, przejdź do katalogu, który zawiera loadgen:

cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/loadgen

5) Utwórz następujące zmienne środowiskowe:

export SERVER_ADDR=http://localhost:8080
export REQUESTS_PER_SECOND=5

6) Uruchom virtualenv:

virtualenv --python python3 env

7) Aktywuj środowisko wirtualne:

source env/bin/activate

8) Zainstaluj wymagania dla loadgen:

pip3 install -r requirements.txt

9) Uruchom loadgen:

python3 loadgen.py

Po uruchomieniu loadgen wyświetli około następującego komunikatu:

Rozpoczynanie loadgen: 2019-05-20 10:44:12.448415
5 zapytanie/zapytania zakończone do http://localhost:8080

W innym oknie terminala server wyświetli około następujących komunikatów:

127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 -
INFO:root:GET request,
Ścieżka: /
Nagłówki:
Host: localhost:8080
User-Agent: python-requests/2.22.0
Accept-Encoding: gzip, deflate
Accept: */*

Z perspektywy sieci, całe aplikacje działają na jednym hoście (lokalnym komputerze lub maszynie wirtualnej Cloud Shell). Dlatego można używać localhost, aby wysyłać żądania do server.
10) Aby zatrzymać loadgen i server, wpisz Ctrl-c w każdym oknie terminala.
11) W oknie terminala loadgen dezaktywuj środowisko wirtualne:

deactivate

Pakowanie aplikacji w kontenery

Aby uruchomić aplikację na GKE, musisz spakować przykładową aplikację — server i loadgen — w kontenery. Kontener to sposób na spakowanie aplikacji, aby odizolować ją od otoczenia.

Aby spakować aplikację w kontener, potrzebny jest Dockerfile. Dockerfile — to plik tekstowy, który definiuje polecenia do budowy kodu źródłowego aplikacji i jej zależności w obraz Docker. Po zbudowaniu przesyłasz obraz do rejestru kontenerów, na przykład Docker Hub lub Container Registry.

W przykładzie już znajdują się Dockerfile do server i loadgen ze wszystkimi niezbędnymi poleceniami do zbudowania obrazów. Poniżej — Dockerfile do server:

FROM python:3-slim as base
FROM base as builder
RUN apt-get -qq update 
    && apt-get install -y --no-install-recommends 
        g++ 
    && rm -rf /var/lib/apt/lists/*

# Włącz nielogowane logowanie
FROM base as final
ENV PYTHONUNBUFFERED=1

RUN apt-get -qq update 
    && apt-get install -y --no-install-recommends 
        wget

WORKDIR /helloserver

# Pobierz pakiety z budowniczego
COPY --from=builder /usr/local/lib/python3.7/ /usr/local/lib/python3.7/

# Dodaj aplikację
COPY . .

EXPOSE 8080
ENTRYPOINT [ "python", "server.py" ]

Zespół FROM python:3-slim as base nakazuje Docker użyć najnowszego obrazu Python 3 jako podstawowego.
Zespół COPY. . kopiuje pliki źródłowe do aktualnego katalogu roboczego (w naszym przypadku tylko server.py) do systemu plików kontenera.
PUNKCIE WEJŚCIA definiuje polecenie, które jest używane do uruchomienia kontenera. W naszym przypadku to polecenie jest prawie to samo, które użyłeś do uruchomienia server.py z kodu źródłowego.
Zespół EXPOSE wskazuje, że server oczekuje danych przez port 8080. To polecenie nie udostępnia porty.To coś w rodzaju dokumentacji, która jest potrzebna, aby otworzyć port 8080 przy uruchamianiu kontenera.

Przygotowanie aplikacji do konteneryzacji

1) Ustaw następujące zmienne środowiskowe. Zamień PROJECT_ID na identyfikator swojego projektu GCP.

export PROJECT_ID="PROJECT_ID"

export GCR_REPO="preparing-istio"

Za pomocą wartości PROJECT_ID i GCR_REPO oznaczasz obraz Docker, gdy go budujesz i przesyłasz do prywatnego Container Registry.

2) Ustaw domyślny projekt GCP dla narzędzia wiersza poleceń gcloud.

gcloud config set project $PROJECT_ID

3) Ustaw domyślną strefę dla narzędzia wiersza poleceń gcloud.

gcloud config set compute/zone us-central1-b

4) Upewnij się, że usługa Container Registry jest włączona w projekcie GCP.

gcloud services enable containerregistry.googleapis.com

Konteneryzacja serwera

Przejdź do katalogu, w którym znajduje się przykład server:

cd TWOJ_DYREKTORIUM_ROBOCZE/istio-samples/sample-apps/helloserver/server/

Zbuduj obraz za pomocą Dockerfile i zmiennych środowiskowych, które wcześniej określiłeś:
```
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .
```

Parametr -t reprezentuje tag Docker. To jest nazwa obrazu, której używasz podczas wdrażania kontenera.

Wyślij obraz do Container Registry:

docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

Konteneryzacja loadgen

1) Przejdź do katalogu, w którym znajduje się przykład loadgen:

cd ../loadgen

2) Zbuduj obraz:

docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1 .

3) Wyślij obraz do Container Registry:

docker push gcr.io/$PROJECT_ID/$GCR_REPO/loadgen:v0.0.1

Wyświetl listę obrazów

Zobacz listę obrazów w repozytorium i upewnij się, że obrazy zostały wysłane:

gcloud container images list --repository gcr.io/$PROJECT_ID/preparing-istio

Polecenie zwraca nazwy właśnie wysłanych obrazów:

NAZWA
gcr.io/PROJECT_ID/preparing-istio/helloserver
gcr.io/PROJECT_ID/preparing-istio/loadgen

Tworzenie klastra GKE.

Te kontenery można uruchomić na maszynie wirtualnej Cloud Shell lub na komputerze poleceniem docker run. Jednak w środowisku produkcyjnym potrzebny jest sposób na centralne orkiestracja kontenerów. Na przykład potrzebny jest system, który monitoruje, aby kontenery zawsze działały i sposób na zwiększenie skali i uruchomienie dodatkowych instancji kontenerów, jeśli ruch wzrośnie.

Do uruchamiania aplikacji kontenerowych można wykorzystać GKE. GKE to platforma orkiestracji kontenerów, która łączy maszyny wirtualne w klaster. Każda maszyna wirtualna nazywana jest węzłem. klastry GKE opierają się na otwartoźródłowym systemie zarządzania klastrami Kubernetes. Kubernetes zapewnia mechanizmy interakcji z klastrem.

Tworzenie klastra GKE:

1) Utwórz klaster:

gcloud container clusters create istioready 
  --cluster-version latest 
  --machine-type=n1-standard-2 
  --num-nodes 4

Zespół gcloud tworzy klaster istioready w projekcie GCP i domyślnej strefie, które określiłeś. Aby uruchomić Istio, zaleca się posiadanie co najmniej 4 węzłów i maszyny wirtualnej n1-standard-2.

Polecenie tworzy klaster przez kilka minut. Gdy klaster będzie gotowy, polecenie zwraca coś podobnego wiadomość.

2) Ustaw dane logowania w narzędziu wiersza poleceń kubectl, aby móc zarządzać klastrem:

gcloud container clusters get-credentials istioready

3) Teraz możesz komunikować się z Kubernetes przez kubectl. Na przykład za pomocą następującego polecenia możesz sprawdzić stan węzłów:

kubectl get nodes

Polecenie zwraca listę węzłów:

NAZWA                                       STATUS   ROLE    WIEK    WERSJA
gke-istoready-default-pool-dbeb23dc-1vg0   Gotowy    <brak>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-36z5   Gotowy    <brak>   100s   v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-fj7s   Gotowy    <brak>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-wbjw   Gotowy    <brak>   99s    v1.13.6-gke.13

Kluczowe pojęcia Kubernetes

Na schemacie przedstawiono aplikację na GKE:

Zanim wdrożysz kontenery w GKE, zapoznaj się z kluczowymi pojęciami Kubernetes. Na końcu znajdują się linki, jeśli chcesz dowiedzieć się więcej.

Węzły i klastry. W GKE węzeł to maszyna wirtualna. Na innych platformach Kubernetes węzłem może być komputer lub maszyna wirtualna. Klaster to zbiór węzłów, które można traktować jako całość, w której wdrażasz zcontainerizowaną aplikację.
Pod’y. W Kubernetes kontenery uruchamiane są w pod’ach. Pod w Kubernetes to jednostka niepodzielna. Pod może zawierać jeden lub więcej kontenerów. Wdrażasz kontenery server i loadgen w oddzielnych pod’ach. Gdy w pod’zie znajdują się różne kontenery (na przykład serwer aplikacji i proxy-serwer), kontenery są zarządzane jako jeden obiekt i wspólnie korzystają z zasobów pod’a.
Wdrożenia. W Kubernetes wdrożenie to obiekt, który reprezentuje zestaw identycznych pod’ów. Wdrożenie uruchamia kilka replik pod’ów, rozłożonych po węzłach klastra. Wdrożenie automatycznie wymienia pod’y, które uległy awarii lub nie odpowiadają.
Serwis Kubernetes. Gdy uruchamiasz kod aplikacji w GKE, zmienia się połączenie między loadgen i server. Kiedy uruchamiałeś serwisy na maszynie wirtualnej Cloud Shell lub na komputerze, wysyłałeś zapytania do server pod adresem localhost:8080. Po wdrożeniu w GKE pod’y działają na dostępnych węzłach. Domyślnie nie możesz zarządzać tym, na którym węźle uruchomiony jest pod, więc nie pod’y nie mają stałych adresów IP.
Aby uzyskać adres IP dla server, musisz określić abstrakcję sieci nad pod’ami. To jest serwis Kubernetes. Serwis Kubernetes zapewnia stały punkt końcowy dla zestawu pod’ów. Istnieje kilka typów serwisów. server używa LoadBalancer, który zapewnia zewnętrzny adres IP, aby połączyć się z server z zewnątrz klastra.
Ponadto, w Kubernetes istnieje wbudowany system DNS, który przypisuje nazwy DNS (na przykład, helloserver.default.cluster.local) usług. Dzięki temu pod'y wewnątrz klastra łączą się z innymi pod'ami w klastrze pod stałym adresem. Nazwa DNS nie może być używana poza klastrem, na przykład w Cloud Shell lub na komputerze.

Manifesty Kubernetes

Gdy uruchamiałeś aplikację z kodu źródłowego, używałeś imperatywnej komendy python3

server.py

Imperatywność oznacza czasownik: "zrób to".

Kubernetes używa modelu deklaratywnego. Oznacza to, że nie mówimy Kubernetes, co dokładnie ma robić, lecz opisujemy pożądany stan. Na przykład, Kubernetes uruchamia i zatrzymuje pod'y w miarę potrzeby, aby rzeczywisty stan systemu odpowiadał pożądanemu.

Pożądany stan określasz w manifestach lub plikach YAML. Plik YAML zawiera specyfikacje dla jednego lub kilku obiektów Kubernetes.

W przykładzie znajduje się plik YAML dla server i loadgen. Każdy plik YAML określa pożądany stan obiektu wdrożenia i serwisu Kubernetes.

server.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloserver
spec:
  selector:
    matchLabels:
      app: helloserver
  replicas: 1
  template:
    metadata:
      labels:
        app: helloserver
    spec:
      terminationGracePeriodSeconds: 5
      restartPolicy: Always
      containers:
      - name: main
        image: gcr.io/google-samples/istio/helloserver:v0.0.1
        imagePullPolicy: Always

kind określa typ obiektu.
metadata.name określa nazwę wdrożenia.
Pierwsze pole spec zawiera opis pożądanego stanu.
spec.replicas określa pożądaną liczbę pod'ów.
Sekcja spec.template określa szablon pod'a. W specyfikacji pod'ów znajduje się pole image, w którym podaje się nazwę obrazu, który ma być pobrany z Container Registry.

Serwis definiuje się w następujący sposób:

apiVersion: v1
kind: Service
metadata:
  name: hellosvc
spec:
  type: LoadBalancer
  selector:
    app: helloserver
  ports:
  - name: http
    port: 80
    targetPort: 8080

LoadBalancer: klienci wysyłają zapytania na adres IP zrównoważacza obciążenia, który ma stały adres IP i który jest dostępny spoza klastra.
targetPort: jak pamiętasz, komenda EXPOSE 8080 do Dockerfile nie udostępniała portów. Udostępniasz port 8080, aby można było połączyć się z kontenerem server na zewnątrz klastra. W naszym przypadku hellosvc.default.cluster.local:80 (krótkie imię: hellosvc) odpowiada portowi 8080 adresu IP pod'a helloserver.
port: to numer portu, na który inne serwisy w klastrze będą wysyłać zapytania.

loadgen.yaml

Obiekt wdrożenia w loadgen.yaml jest podobny do server.yaml. Różnica polega na tym, że obiekt wdrożenia zawiera sekcję env. Określa zmienne środowiskowe, które są potrzebne. loadgen i które zainstalowałeś podczas uruchamiania aplikacji z kodu źródłowego.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: loadgenerator
spec:
  selector:
    matchLabels:
      app: loadgenerator
  replicas: 1
  template:
    metadata:
      labels:
        app: loadgenerator
    spec:
      terminationGracePeriodSeconds: 5
      restartPolicy: Always
      containers:
      - name: main
        image: gcr.io/google-samples/istio/loadgen:v0.0.1
        imagePullPolicy: Always
        env:
        - name: SERVER_ADDR
          value: "http://hellosvc:80/"
        - name: REQUESTS_PER_SECOND
          value: "10"
        resources:
          requests:
            cpu: 300m
            memory: 256Mi
          limits:
            cpu: 500m
            memory: 512Mi

Raz loadgen nie akceptuje przychodzących zapytań, dla pola type podano ClusterIP. Ten typ zapewnia stały adres IP, który mogą wykorzystywać usługi w klastrze, ale ten adres IP nie jest udostępniany klientom zewnętrznym.

apiVersion: v1
kind: Service
metadata:
  name: loadgensvc
spec:
  type: ClusterIP
  selector:
    app: loadgenerator
  ports:
  - name: http
    port: 80
    targetPort: 8080

Wdrażanie kontenerów w GKE

1) Przejdź do katalogu, w którym znajduje się przykład server:

cd TWOJ_DYREKTORIUM_ROBOCZE/istio-samples/sample-apps/helloserver/server/

2) Otwórz server.yaml w edytorze tekstu.
3) Zmień nazwę w polu image na nazwę swojego obrazu Docker.

image: gcr.io/PROJECT_ID/preparing-istio/helloserver:v0.0.1

Zastąp PROJECT_ID na identyfikator swojego projektu GCP.
4) Zapisz i zamknij server.yaml.
5) Wdróż plik YAML w Kubernetes:

kubectl apply -f server.yaml

Po pomyślnym zakończeniu komenda zwraca następujący kod:

deployment.apps/helloserver created
service/hellosvc created

6) Przejdź do katalogu, w którym znajduje się loadgen:

cd ../loadgen

7) Otwórz loadgen.yaml w edytorze tekstu.
8) Zmień nazwę w polu image na nazwę swojego obrazu Docker.

image: gcr.io/PROJECT_ID/preparing-istio/loadgenv0.0.1

Zastąp PROJECT_ID na identyfikator swojego projektu GCP.
9) Zapisz i zamknij loadgen.yaml, zamknij edytor tekstu.
10) Wdróż plik YAML w Kubernetes:

kubectl apply -f loadgen.yaml

Po pomyślnym zakończeniu komenda zwraca następujący kod:

deployment.apps/loadgenerator created
service/loadgensvc created

11) Sprawdź status podów:

kubectl get pods

Komenda pokazuje status:

NAZWA                             GOTOWY   STATUS    RESTARTY   WIEK
helloserver-69b9576d96-mwtcj     1/1     Działa   0          58s
loadgenerator-774dbc46fb-gpbrz   1/1     Działa   0          57s

12) Wyciągnij logi aplikacji z poda loadgen. Zmień POD_ID na identyfikator z poprzedniej odpowiedzi.

kubectl logs loadgenerator-POD_ID

13) Uzyskaj zewnętrzne adresy IP hellosvc:

kubectl get service

Odpowiedź komendy wygląda mniej więcej tak:

NAZWA         TYP           CLUSTER-IP     EXTERNAL-IP     PORT(Y)        WIEK
hellosvc     LoadBalancer   10.81.15.158   192.0.2.1       80:31127/TCP   33m
kubernetes   ClusterIP      10.81.0.1                443/TCP        93m
loadgensvc   ClusterIP      10.81.15.155             80/TCP         4m52s

14) Wyślij zapytanie do hellosvc: zamień EXTERNAL_IP na zewnętrzny adres IP hellosvc.

curl http://EXTERNAL_IP

Przechodzimy do Istio

Masz już aplikację wdrożoną w GKE. loadgen może korzystać z DNS Kubernetes (hellosvc:80), aby wysyłać zapytania do server, i możesz wysyłać zapytania do server po zewnętrznym adresie IP. Chociaż Kubernetes ma wiele możliwości, niektóre informacje o usługach są niedostępne:

Jak działają usługi? Jakie są relacje pomiędzy usługami? Jak przebiega ruch pomiędzy usługami? Wiesz, że loadgen wysyła zapytania do server, ale wyobraź sobie, że nic nie wiesz o aplikacji. Aby odpowiedzieć na te pytania, spojrzymy na listę uruchomionych podów w GKE.
Metryki. Jak długo server odpowiada na przychodzące zapytanie? Ile zapytań na sekundę trafia na serwer? Zgłasza komunikaty o błędach?
Informacje o bezpieczeństwie. Ruch między loadgen i server przechodzi po prostu przez HTTP lub przez mTLS?

Na wszystkie te pytania odpowiada Istio. W tym celu Istio umieszcza proxy sidecar Envoy w każdym podzie. Proxy Envoy przechwytuje cały przychodzący i wychodzący ruch do kontenerów aplikacji. Oznacza to, że server i loadgen otrzymują przez proxy sidecar Envoy, a cały ruch od loadgen do server przechodzi przez proxy Envoy.

Połączenia pomiędzy proxy Envoy tworzą service mesh. Architektura service mesh zapewnia dodatkowy poziom kontroli nad Kubernetes.

Ponieważ proxy Envoy działają w swoich kontenerach, Istio można zainstalować na klastrze GKE, prawie nie zmieniając kodu aplikacji. Jednak wykonaliście pewną pracę, aby przygotować aplikację do zarządzania za pomocą Istio:

Usługi dla wszystkich kontenerów. Do wdrożeń server i loadgen jest przypisana jedna usługa Kubernetes. Nawet usługa, loadgendo której nie trafiają przychodzące zapytania, ma usługę.
Porty w usługach muszą mieć nazwy. Chociaż w GKE porty usług można pozostawić bez nazwy, Istio wymaga podania nazwa portu zgodnie z jego protokołem. W pliku YAML port dla server nazywa się http, ponieważ serwer używa protokołu HTTP. Gdyby service korzystał z gRPC, nazwałbyś port grpc.
Wdrożenia są oznaczane. Dzięki temu możesz korzystać z funkcji zarządzania ruchem Istio, takich jak dzielenie ruchu między wersjami jednej usługi.

Instalacja Istio

Istio można zainstalować na dwa sposoby. Możesz włączyć rozszerzenie Istio on GKE lub zainstalować wersję open-source Istio na klastrze. Dzięki Istio on GKE łatwo zarządzać instalacją i aktualizacją Istio w ramach cyklu życia klastra GKE. Jeśli potrzebujesz najnowszej wersji Istio lub większej kontroli nad konfiguracją panelu sterowania Istio, zainstaluj wersję open-source zamiast rozszerzenia Istio on GKE. Aby zdecydować, który sposób jest lepszy, przeczytaj artykuł Czy potrzebuję Istio on GKE?.

Wybierz opcję, zapoznaj się z odpowiednim przewodnikiem i postępuj zgodnie z instrukcjami, aby zainstalować Istio na klastrze. Jeśli chcesz używać Istio z właśnie wdrożoną aplikacją, włącz wdrażanie sidecar’ów dla przestrzeni nazw default.

Wyczyść

Aby uniknąć naliczania opłat za zasoby używane w tym przewodniku z konta Google Cloud Platform, usuń klaster kontenerów po zainstalowaniu Istio i przetestowaniu przykładowej aplikacji. W ten sposób usunięte będą wszystkie zasoby klastra, w tym instancje obliczeniowe, dyski i zasoby sieciowe.