🥇Падрыхтоўка прыкладання для Istio

Istio - гэта зручны інструмент для злучэння, абароны і маніторынгу размеркаваных прыкладанняў. У Istio выкарыстоўваюцца розныя тэхналогіі для маштабнага запуску ПЗ і кіравання ім, уключаючы кантэйнеры для пакавання кода прыкладання і залежнасцяў для разгортвання і Kubernetes – для кіравання гэтымі кантэйнерамі. Таму для працы з Istio вы павінны ведаць, як дадатак з некалькімі сэрвісамі на аснове гэтых тэхналогій працуе без Istio. Калі гэтыя прылады і паняцці вам ужо знаёмыя, адважна прапускайце гэта кіраўніцтва і пераходзіце прама да часткі Усталяванне Istio на Google Kubernetes Engine (GKE) або ўстаноўцы пашырэння Istio on GKE.

Гэта пакрокавае кіраўніцтва, дзе мы разгледзім увесь працэс ад зыходнага кода да кантэйнера на GKE, каб вы атрымалі базавую ўяўленне аб гэтых тэхналогіях на прыкладзе. Таксама вы ўбачыце, як Istio выкарыстоўвае магчымасці гэтых тэхналогій. Мяркуецца, што вы не ведаеце нічога аб кантэйнерах, Kubernetes, Service Mesh або Istio.

задачы

У гэтым кіраўніцтве вы выканаеце наступныя задачы:

Вывучэнне простага прыкладання hello world з некалькімі службамі.
Запуск дадатак з зыходнага кода.
Упакоўка прыкладання ў кантэйнеры.
Стварэнне кластара Kubernetes.
Разгортванне кантэйнераў у кластар.

Перш чым пачаць

Выконвайце інструкцыі, каб уключыць Kubernetes Engine API:

зайдзіце на старонку Kubernetes Engine у кансолі Google Cloud Platform.
Стварыце або абярыце праект.
Пачакайце, пакуль уключыцца API і злучаныя службы. Гэта можа заняць некалькі хвілін.
Упэўніцеся, што для праекта Google Cloud Platform настроена выстаўленне рахункаў. Даведайцеся, як уключыць выстаўленне рахункаў.

У гэтым кіраўніцтве можна выкарыстоўваць Cloud Shell, які падрыхтоўвае віртуальную машыну g1-small у Google Compute Engine з Linux на аснове Debian, ці кампутар на Linux ці macOS.

Варыянт А: выкарыстанне Cloud Shell

Перавагі выкарыстання Cloud Shell:

Асяроддзя распрацоўкі Python 2 і Python 3 (уключаючы virtualenv) цалкам настроены.
Інструменты каманднага радка gcloud, докер, мярзотнік и кубектль, якія мы будзем выкарыстоўваць, ужо ўстаноўлены.
У вас на выбар некалькі тэкставых рэдактараў:
1. Рэдактар кода, які адкрываецца значком рэдагавання ў верхняй частцы акна Cloud Shell.
2. Emacs, Vim або Nano, якія адчыняюцца з каманднага радка ў Cloud Shell.

каб выкарыстоўваць Воблачная абалонка:

Перайдзіце ў кансоль GCP.
націсніце кнопку Activate Cloud Shell (Актываваць Cloud Shell) у верхняй частцы акна кансолі GCP.

У ніжняй частцы кансолі GCP у новым акне адкрыецца сеанс Cloud Shell з камандным радком.

Варыянт Б: выкарыстанне прылад каманднага радка лакальна

Калі вы будзеце працаваць на кампутары з Linux ці macOS, трэба наладзіць і ўсталяваць наступныя кампаненты:

Наладзьце асяроддзе распрацоўкі Python 3 і Python 2.
Усталюйце Cloud SDK з інструментам каманднага радка gcloud.
Усталюйце кубектль - інструмент каманднага радка для працы з Kubernetes.
```
gcloud components install kubectl
```
Усталюйце Docker Community Edition (CE). Вы будзеце выкарыстоўваць інструмент каманднага радка докер, Каб ствараць выявы кантэйнераў для прыкладу прыкладання.
Усталюйце інструмент кантролю версій Git, Каб атрымаць прыклад прыкладання з GitHub.

Загрузка прыкладу кода

Загрузіце зыходны код helloserver:

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

Перайдзіце ў каталог прыкладу кода:
```
cd istio-samples/sample-apps/helloserver
```

Вывучэнне прыкладання з некалькімі сэрвісамі

Прыклад дадатку напісаны на Python і складаецца з двух кампанентаў, якія ўзаемадзейнічаюць з дапамогай REST:

сервер: просты сервер з адной канчатковай кропкай GET, /, які выводзіць "hello world" на кансолі
loadgen: скрыпт, які пасылае трафік на сервер, з наладжвальным лікам запытаў у секунду.

Запуск прыкладання з зыходнага кода

Каб вывучыць прыклад прыкладання, запусціце яго ў Cloud Shell ці на кампутары.
1) У каталогу istio-samples/sample-apps/helloserver запусціце сервер:

python3 server/server.py

пры запуску сервер адлюстроўваецца наступнае:

INFO:root:Starting server...

2) Адкрыйце іншае акно тэрмінала, каб адпраўляць запыты да сервер. Калі вы карыстаецеся Cloud Shell, націсніце значок дадання, каб адкрыць іншы сеанс.
3) Адпраўце запыт да сервер:

curl http://localhost:8080

server адказвае:

Hello World!

4) З каталога, куды вы загрузілі прыкладу кода, перайдзіце ў каталог, які змяшчае loadgen:

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

5) Стварыце наступныя зменныя асяроддзі:

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

6) Запусціце virtualenv:

virtualenv --python python3 env

7) Актывуйце віртуальнае асяроддзе:

source env/bin/activate

8) Усталюйце патрабаванні для loadgen:

pip3 install -r requirements.txt

9) Запусціце loadgen:

python3 loadgen.py

пры запуску loadgen выводзіць прыкладна наступнае паведамленне:

Starting loadgen: 2019-05-20 10:44:12.448415
5 request(s) complete to http://localhost:8080

У іншым акне тэрмінала сервер выводзіць на кансоль прыкладна наступныя паведамленні:

127.0.0.1 - - [21/Jun/2019 14:22:01] "GET / HTTP/1.1" 200 -
INFO:root:GET request,
Path: /
Headers:
Host: localhost:8080
User-Agent: python-requests/2.22.0
Accept-Encoding: gzip, deflate
Accept: */*

З пункту гледжання сеткі, усё прыкладанне працуе на адным хасце (лакальным кампутары ці віртуальнай машыне Cloud Shell). Таму можна выкарыстоўваць лакальны, Каб адпраўляць запыты да сервер.
10) Каб спыніць loadgen и сервер, увядзіце Ctrl-c у кожным акне тэрмінала.
11) У акне тэрмінала loadgen дэактывуйце віртуальнае асяроддзе:

deactivate

Упакоўка прыкладання ў кантэйнеры

Каб запусціць прыкладанне на GKE, трэба спакаваць прыклад прыкладання - сервер и loadgen - у кантэйнеры. Кантэйнер - гэта спосаб спакаваць прыкладанне, каб ізаляваць яго ад асяроддзя.

Каб спакаваць прыкладанне ў кантэйнер, патрэбен Докер-файл. Докер-файл - Гэта тэкставы файл, дзе вызначаюцца каманды для зборкі зыходнага кода прыкладання і яго залежнасцяў у вобраз Docker. Пасля зборкі вы загружаеце выяву ў рэестр кантэйнераў, напрыклад Docker Hub або Рэестр кантэйнераў.

У прыкладзе ўжо ёсць Докер-файл для сервер и loadgen з усімі патрэбнымі камандамі, каб сабраць выявы. Ніжэй Докер-файл для сервер:

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/*

# Enable unbuffered logging
FROM base as final
ENV PYTHONUNBUFFERED=1

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

WORKDIR /helloserver

# Grab packages from builder
COPY --from=builder /usr/local/lib/python3.7/ /usr/local/lib/python3.7/

# Add the application
COPY . .

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

Каманда FROM python:3-slim as base загадвае Docker выкарыстоўваць апошні вобраз Python 3 у якасці базавага.
Каманда COPY. . капіюе зыходныя файлы ў бягучы працоўны каталог (у нашым выпадку толькі server.py) у файлавую сістэму кантэйнера.
ENTRYPOINT вызначае каманду, якая выкарыстоўваецца для запуску кантэйнера. У нашым выпадку гэтая каманда амаль супадае з той, якую вы выкарыстоўвалі для запуску server.py з зыходнага кода.
Каманда ВЫКРЫЦЬ паказвае, што сервер чакае дадзеныя праз порт 8080. Гэтая каманда не дае парты. Гэта нешта накшталт дакументацыі, якая патрэбна, каб адкрыць порт 8080 пры запуску кантэйнера.

Падрыхтоўка да кантэйнерызацыі прыкладання

1) Задайце наступныя зменныя асяроддзі. Замяніце PROJECT_ID на ідэнтыфікатар свайго праекту GCP.

export PROJECT_ID="PROJECT_ID"

export GCR_REPO="preparing-istio"

З дапамогай значэнняў PROJECT_ID и GCR_REPO вы пазначаеце выяву Docker, калі збіраеце і адпраўляеце яго ў прыватны Container Registry.

2) Задайце праект GCP па змаўчанні для прылады каманднага радка gcloud.

gcloud config set project $PROJECT_ID

3) Задайце зону па змаўчанні для прылады каманднага радка gcloud.

gcloud config set compute/zone us-central1-b

4) Пераканайцеся, што сэрвіс Container Registry уключаны ў праекце GCP.

gcloud services enable containerregistry.googleapis.com

Кантэйнерызацыя server

Перайдзіце ў каталог, дзе знаходзіцца прыклад сервер:
```
cd YOUR_WORKING_DIRECTORY/istio-samples/sample-apps/helloserver/server/
```
Збярыце вобраз з дапамогай Докер-файл і зменных асяроддзя, якія вы вызначылі раней:
```
docker build -t gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1 .
```

Параметр -t уяўляе тэг Docker. Гэта імя выявы, які вы выкарыстоўваеце пры разгортванні кантэйнера.

Адпраўце выяву ў Container Registry:

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

Кантэйнерызацыя loadgen

1) Перайдзіце ў каталог, дзе знаходзіцца прыклад loadgen:

cd ../loadgen

2) Збярыце вобраз:

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

3) Адпраўце выяву ў Container Registry:

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

Прагляд спісу выяў

Праглядзіце спіс выяў у рэпазітары і пераканаецеся, што выявы адпраўленыя:

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

Каманда выдае імёны толькі што адпраўленых вобразаў:

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

Стварэнне кластара GKE.

Гэтыя кантэйнеры можна было б запусціць на віртуальнай машыне Cloud Shell ці на кампутары камандай докер прабег. Але ў вытворчым асяроддзі патрэбен спосаб цэнтралізавана аркестраваць кантэйнеры. Напрыклад, патрэбна сістэма, якая сочыць, каб кантэйнеры заўсёды працавалі, і патрэбен спосаб павялічваць маштаб і запускаць дадатковыя асобнікі кантэйнераў, калі трафік узрасце.

Для запуску кантэйнерных прыкладанняў можна выкарыстоўваць ГКЕ. GKE - гэта платформа аркестрацыі кантэйнераў, якая аб'ядноўвае віртуальныя машыны ў кластар. Кожная віртуальная машына называецца вузлом. Кластары GKE заснаваны на апенсорс-сістэме кіравання кластарамі Kubernetes. Kubernetes дае механізмы ўзаемадзеяння з кластарам.

Стварэнне кластара GKE:

1) Стварыце кластар:

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

Каманда gcloud стварае кластар istioready ў праекце GCP і зоне па змаўчанні, якія вы паказалі. Каб запусціць Istio, рэкамендуем мець хаця б 4 вузла і віртуальную машыну n1-standard-2.

Каманда стварае кластар некалькі хвілін. Калі кластар будзе гатовы, каманда выдае падобнае паведамленне.

2) Запішыце ўліковыя дадзеныя ў інструменце каманднага радка кубектль, Каб з яе дапамогай кіраваць кластарам:

gcloud container clusters get-credentials istioready

3) Цяпер можна мець зносіны з Kubernetes праз кубектль. Напрыклад, наступнай камандай можна даведацца пра статус вузлоў:

kubectl get nodes

Каманда выдае спіс вузлоў:

NAME                                       STATUS   ROLES    AGE    VERSION
gke-istoready-default-pool-dbeb23dc-1vg0   Ready    <none>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-36z5   Ready    <none>   100s   v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-fj7s   Ready    <none>   99s    v1.13.6-gke.13
gke-istoready-default-pool-dbeb23dc-wbjw   Ready    <none>   99s    v1.13.6-gke.13

Ключавыя паняцці Kubernetes

На схеме паказана дадатак на GKE:

Перш чым разгарнуць кантэйнеры ў GKE, вывучыце ключавыя паняцці Kubernetes. У самым канцы ёсць спасылкі, калі вы хочаце даведацца больш.

Вузлы і кластары. У GKE вузел - гэта віртуальная машына. На іншых платформах Kubernetes вузлом можа быць кампутар ці віртуальная машына. Кластар - гэта набор вузлоў, якія можна лічыць адзіным цэлым і дзе вы разгортваеце кантэйнерызаванае прыкладанне.
Pod'ы. У Kubernetes кантэйнеры запускаюцца ў pod'ах. Pod у Kubernetes - гэта непадзельная адзінка. Pod месціць адзін або некалькі кантэйнераў. Вы разгортваеце кантэйнеры server і loadgen у асобных pod'ах. Калі ў pod'е некалькі кантэйнераў (напрыклад, сервер прыкладання і проксі-сервер), кантэйнеры кіруюцца як адзіны аб'ект і сумесна выкарыстоўваюць рэсурсы pod'а.
Разгортвання. У Kubernetes разгортванне - гэта аб'ект, які ўяўляе сабой набор ідэнтычных pod'ов. Разгортванне запускае некалькі рэплік pod'ов, размеркаваных па вузлах кластара. Разгортванне аўтаматычна замяняе pod'ы, якія адмовілі ці не адказваюць.
Сэрвіс Kubernetes. Пры запуску кода прыкладання ў GKE мяняецца злучэнне паміж loadgen и сервер. Калі вы запусцілі сэрвісы на віртуальнай машыне Cloud Shell ці на кампутары, вы адпраўлялі запыты да сервер па адрасе лакальны: 8080. Пасля разгортвання ў GKE pod'ы выконваюцца на даступных вузлах. Па змаўчанні вы ніяк не можаце кіраваць тым, на якім вузле запушчаны pod, так што ў pod'аў няма пастаянных IP-адрасоў.
Каб атрымаць IP-адрас для сервер, трэба вызначыць абстракцыю сеткі па-над pod'аў. Гэта і ёсць сэрвіс Kubernetes. Сэрвіс Kubernetes падае сталую канчатковую кропку для набору pod'аў. Ёсць некалькі тыпаў сэрвісаў. сервер выкарыстоўвае LoadBalancer, Які дае знешні IP-адрас, каб звязацца з сервер з-за межаў кластара.
Яшчэ ў Kubernetes ёсць убудаваная сістэма DNS, якая прызначае імёны DNS (напрыклад, helloserver.default.cluster.local) сэрвісам. Дзякуючы гэтаму pod'ы ўсярэдзіне кластара звязваюцца з іншымі pod'амі ў кластары па сталым адрасе. Імя DNS нельга выкарыстоўваць па-за межамі кластара, напрыклад у Cloud Shell або на кампутары.

Маніфесты Kubernetes

Калі вы запускалі дадатак з зыходнага кода, вы выкарыстоўвалі імператыўную каманду python3

server.py

Імператыўнасць мае на ўвазе дзеяслоў: "зрабі гэта".

Kubernetes выкарыстоўвае дэкларатыўную мадэль. Гэта значыць, што мы не гаворым Kubernetes, што менавіта трэба рабіць, а апісваем жаданае стан. Напрыклад, Kubernetes запускае і спыняе pod'ы па меры неабходнасці, каб фактычны стан сістэмы адпавядаў жаданаму.

Жаданы стан вы паказваеце ў маніфестах, ці файлах YAML. Файл YAML утрымоўвае спецыфікацыі для аднаго ці некалькіх аб'ектаў Kubernetes.

У прыкладзе змяшчаецца файл YAML для сервер и loadgen. Кожны файл YAML паказвае жаданае стан аб'екта разгортвання і сэрвісу 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

выгляд паказвае тып аб'екта.
metadata.name паказвае імя разгортвання.
Першае поле спекуляцыя змяшчае апісанне жаданага стану.
spec.replicas паказвае жаданую колькасць pod'аў.
Раздзел spec.template вызначае шаблон pod'а. У спецыфікацыі pod'ов ёсць поле малюнак, дзе паказваецца імя выявы, які трэба атрымаць з Container Registry.

Сэрвіс вызначаецца наступным чынам:

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

LoadBalancer: кліенты адпраўляюць запыты на IP-адрас балансавальніка нагрузкі, у якога ёсць пастаянны IP-адрас і які даступны з-за межаў кластара.
targetPort: як вы памятаеце, каманда EXPOSE 8080 в Докер-файл не давала парты. Вы дае порт 8080, каб можна было звязацца з кантэйнерам сервер звонку кластара. У нашым выпадку hellosvc.default.cluster.local:80 (кароткае імя: hellosvc) адпавядае порце 8080 IP-адрасы пода helloserver.
порт: гэта нумар порта, куды астатнія сэрвісы ў кластары будуць дасылаць запыты.

loadgen.yaml

Аб'ект разгортвання ў loadgen.yaml падобны на server.yaml. Розніца ў тым, што аб'ект разгортвання змяшчае раздзел env. Ён вызначае зменныя асяроддзі, якія патрэбны loadgen і якія вы ўсталявалі пры запуску прыкладання з зыходнага кода.

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

Раз loadgen не прымае ўваходныя запыты, для поля тып паказана ClusterIP. Гэты тып дае пастаянны IP-адрас, які могуць выкарыстоўваць сэрвісы ў кластары, але гэты IP-адрас не прадастаўляецца знешнім кліентам.

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

Разгортванне кантэйнераў у GKE

1) Перайдзіце ў каталог, дзе знаходзіцца прыклад сервер:

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

2) Адкрыйце server.yaml у тэкставым рэдактары.
3) Заменіце імя ў поле малюнак на імя вашага ладу Docker.

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

заменіце PROJECT_ID на ідэнтыфікатар вашага праекта GCP.
4) Захавайце і зачыніце server.yaml.
5) Разгарніце файл YAML у Kubernetes:

kubectl apply -f server.yaml

Пасля паспяховага завяршэння каманда выдае наступны код:

deployment.apps/helloserver created
service/hellosvc created

6) Перайдзіце ў каталог, дзе знаходзіцца loadgen:

cd ../loadgen

7) Адкрыйце loadgen.yaml у тэкставым рэдактары.
8) Заменіце імя ў поле малюнак на імя вашага ладу Docker.

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

заменіце PROJECT_ID на ідэнтыфікатар вашага праекта GCP.
9) Захавайце і зачыніце loadgen.yaml, зачыніце тэкставы рэдактар.
10) Разгарніце файл YAML у Kubernetes:

kubectl apply -f loadgen.yaml

Пасля паспяховага завяршэння каманда выдае наступны код:

deployment.apps/loadgenerator created
service/loadgensvc created

11) Праверце статус подаў:

kubectl get pods

Каманда паказвае статус:

NAME                             READY   STATUS    RESTARTS   AGE
helloserver-69b9576d96-mwtcj     1/1     Running   0          58s
loadgenerator-774dbc46fb-gpbrz   1/1     Running   0          57s

12) Выміце логі прыкладання з пода loadgen. Замяніце POD_ID на ідэнтыфікатар з папярэдняга адказу.

kubectl logs loadgenerator-POD_ID

13) Атрымайце знешнія IP-адрасы hellosvc:

kubectl get service

Адказ каманды выглядае прыкладна так:

NAME         TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
hellosvc     LoadBalancer   10.81.15.158   192.0.2.1       80:31127/TCP   33m
kubernetes   ClusterIP      10.81.0.1      <none>          443/TCP        93m
loadgensvc   ClusterIP      10.81.15.155   <none>          80/TCP         4m52s

14) Адпраўце запыт да hellosvc: заменіце EXTERNAL_IP на знешні IP-адрас hellosvc.

curl http://EXTERNAL_IP

Бярэмся за Istio

У вас ужо ёсць прыкладанне, разгорнутае ў GKE. loadgen можа выкарыстоўваць Kubernetes DNS (hellosvc:80), каб адпраўляць запыты да сервер, і вы можаце адпраўляць запыты да сервер па вонкавым IP-адрасу. Хоць у Kubernetes шмат магчымасцяў, сякой-такой інфармацыі аб сэрвісах не хапае:

Як узаемадзейнічаюць сэрвісы? Якія адносіны паміж сэрвісамі? Як праходзіць трафік паміж сервісамі? Вы ў курсе, што loadgen адпраўляе запыты да сервер, Але ўявіце, што вы нічога не ведаеце аб дадатку. Каб адказаць на гэтыя пытанні, глядзім на спіс запушчаных подаў у GKE.
Метрыкі. Як доўга сервер адказвае на ўваходны запыт? Колькі запытаў за секунду паступае на server? Ён выдае паведамленні аб памылках?
Звесткі аб бяспецы. Трафік паміж loadgen и сервер праходзіць проста па HTTP або па mTLS?

На ўсе гэтыя пытанні адказвае Istio. Для гэтага Istio змяшчае sidecar-проксі пасланнік у кожны pod. Проксі Envoy перахапляе ўвесь уваходны і выходны трафік да кантэйнераў прыкладання. Гэта азначае, што сервер и loadgen атрымліваюць па sidecar-проксі Envoy, і ўвесь трафік ад loadgen к сервер праходзіць праз проксі Envoy.

Злучэнні паміж проксі Envoy утвораць service mesh. Архітэктура service mesh дае ўзровень кантролю па-над Kubernetes.

Раз проксі Envoy выконваюцца ў сваіх кантэйнерах, Istio можна ўсталяваць па-над кластарам GKE, амаль не змяняючы код прыкладання. Але вы прарабілі такую-сякую працу, каб падрыхтаваць дадатак да кіравання з дапамогай Istio:

Сэрвісы для ўсіх кантэйнераў. Да разгортванняў сервер и loadgen прывязана па сэрвісе Kubernetes. Нават у loadgen, Да якога не паступаюць ўваходныя запыты, ёсць сэрвіс.
У партоў у сэрвісах павінны быць імёны. Хоць у GKE парты сэрвісаў можна пакідаць без імя, Istio патрабуе ўказаць імя порта у адпаведнасці з яго пратаколам. У файле YAML порт для сервер называецца HTTP, таму што server выкарыстоўвае пратакол HTTP. Калі б абслугоўванне выкарыстаў gRPC, вы б назвалі порт групоўка.
Разгортванні адзначаюцца. Таму вы можаце выкарыстоўваць функцыі кіравання трафікам Istio, напрыклад падзяляць трафік паміж версіямі аднаго сэрвісу.

Ўстаноўка Istio

Усталяваць Istio можна двума спосабамі. Можна уключыць пашырэнне Istio on GKE або усталяваць апенсорс-версію Istio на кластары. З Istio on GKE можна лёгка кіраваць усталёўкай і апгрэйдам Istio у рамках жыццёвага цыклу кластара GKE. Калі вам патрэбна самая новая версія Istio або больш кантролю над канфігурацыяй панэлі кіравання Istio, усталюеце апенсорс-версію замест пашырэння Istio on GKE. Каб вызначыцца з падыходам, чытайце артыкул Ці патрэбен мне Istio on GKE?.

Абярыце варыянт, вывучыце адпаведнае кіраўніцтва і прытрымлівайцеся інструкцыям, каб усталяваць Istio на кластары. Калі вы хочаце выкарыстоўваць Istio з толькі што разгорнутым дадаткам, уключыце ўкараненне sidecar'аў для прасторы імёнаў дэфолт.

ачыстка

Каб з акаўнта Google Cloud Platform не спісвалася плата за рэсурсы, якія вы выкарыстоўвалі ў гэтым кіраўніцтве, выдаліце кластар кантэйнера, калі ўсталюеце Istio і найграецеся з прыкладам прыкладання. Пры гэтым будуць выдалены ўсе рэсурсы кластара, напрыклад вылічальныя асобнікі, дыскі і сеткавыя рэсурсы.

Што далей?

Вывучыце наступныя тэхналогіі:
Вывучыце наступныя прылады:
Вывучыце паняцці Kubernetes:

Крыніца: habr.com

Падрыхтоўка прыкладання для Istio