Preparante aplikaĵon por Istio

Preparante aplikaĵon por Istio

Istio estas oportuna ilo por konekti, sekurigi kaj monitori distribuitajn aplikaĵojn. Istio uzas diversajn teknologiojn por ruli kaj administri programaron je skalo, inkluzive de ujoj por paki aplikaĵkodon kaj dependecojn por deplojo, kaj Kubernetes por administri tiujn ujojn. Tial, por labori kun Istio vi devas scii kiel funkcias aplikaĵo kun pluraj servoj bazitaj sur ĉi tiuj teknologioj sen Istio. Se ĉi tiuj iloj kaj konceptoj jam estas konataj al vi, bonvolu preterlasi ĉi tiun lernilon kaj iri rekte al la sekcio Instalante Istio sur Google Kubernetes Engine (GKE) aŭ instali etendon Istio sur GKE.

Ĉi tio estas paŝo post paŝo, kie ni trairos la tutan procezon de fontkodo ĝis GKE-ujo por ke vi ricevu bazan komprenon pri ĉi tiuj teknologioj kun ekzemplo. Vi ankaŭ vidos kiel Istio ekspluatas la potencon de ĉi tiuj teknologioj. Ĉi tio supozas, ke vi scias nenion pri ujoj, Kubernetes, servaj retoj aŭ Istio.

taskoj

En ĉi tiu lernilo, vi plenumos la sekvajn taskojn:

  1. Lernante simplan salutan mondon-aplikaĵon kun pluraj servoj.
  2. Rulu la aplikaĵon de fontkodo.
  3. Pakado de la aplikaĵo en ujoj.
  4. Kreante Kubernetes-grupon.
  5. Deplojante ujojn en areton.

Antaŭ ol komenci

Sekvu la instrukciojn por ebligi la Kubernetes Engine API:

  1. Iru al Paĝo de Kubernetes Engine en la konzolo de Google Cloud Platform.
  2. Kreu aŭ elektu projekton.
  3. Atendu ĝis la API kaj rilataj servoj estas ebligitaj. Ĉi tio povas daŭri kelkajn minutojn.
  4. Certigu, ke fakturado estas agordita por via projekto de Google Cloud Platform. Lernu kiel ebligi fakturadon.

En ĉi tiu lernilo, vi povas uzi Cloud Shell, kiu preparas la virtualan maŝinon g1-malgranda en Google Compute Engine kun Debian-bazita Linukso, aŭ Linukso aŭ macOS-komputilo.

Opcio A: Uzante Cloud Shell

Avantaĝoj de uzado de Cloud Shell:

  • Python 2 kaj Python 3 evolumedioj (inkluzive virtualenv) estas plene agorditaj.
  • Komandliniaj Iloj gcloud, docker, iri и kubectl, kiujn ni uzos jam estas instalitaj.
  • Vi havas plurajn por elekti tekstoredaktiloj:
    1. Kodredaktilo, kiu malfermiĝas per la redakta piktogramo ĉe la supro de la fenestro de Cloud Shell.
    2. Emakso, Vim aŭ Nano, kiuj malfermiĝas de la komandlinio en Cloud Shell.

Uzi Nuba Ŝelo:

  1. Iru al la GCP-konzolo.
  2. gazetaro Aktivigu Cloud Shell (Aktivigu Cloud Shell) ĉe la supro de la GCP-konzola fenestro.

Preparante aplikaĵon por Istio

En la malsupra parto GCP-konzolo Cloud Shell-sesio kun komandlinio malfermos en nova fenestro.

Preparante aplikaĵon por Istio

Opcio B: Uzante Komandliniajn Ilojn Loke

Se vi laboros en komputilo kun Linukso aŭ macOS, vi devos agordi kaj instali la jenajn komponantojn:

  1. Agordu Python 3 kaj Python 2 evolumedio.

  2. Instalu Cloud SDK kun komandlinia ilo gcloud.

  3. Instali kubectl - komandlinia ilo por labori kun Kubernetoj.

    gcloud components install kubectl

  4. Instali Docker Komunuma Eldono (CE). Vi uzos la komandlinian ilon dockerkrei ujajn bildojn por la ekzempla aplikaĵo.

  5. Instalu la ilon Git-versia kontrolopor akiri la specimenan aplikaĵon de GitHub.

Elŝutu specimenan kodon

  1. Elŝutu la fontkodon salutservilo:

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

  2. Iru al la ekzempla koda dosierujo:

    cd istio-samples/sample-apps/helloserver

Esplorante aplikaĵon kun pluraj servoj

La specimena aplikaĵo estas skribita en Python kaj konsistas el du komponantoj, kiuj interagas uzante RESTA:

  • servilo: simpla servilo kun unu finpunkto GET, /, kiu presas "saluton mondo" al la konzolo.
  • loadgen: skripto kiu sendas trafikon al servilo, kun agordebla nombro da petoj sekundo.

Preparante aplikaĵon por Istio

Ruli aplikaĵon de fontkodo

Por esplori la specimenan aplikaĵon, rulu ĝin en Cloud Shell aŭ en via komputilo.
1) En la katalogo istio-samples/sample-apps/helloserver kuri servilo:

python3 server/server.py

Ĉe ekfunkciigo servilo jena montriĝas:

INFO:root:Starting server...

2) Malfermu alian terminalan fenestron por sendi petojn al servilo. Se vi uzas Cloud Shell, alklaku la aldona piktogramon por malfermi alian sesion.
3) Sendu peton al servilo:

curl http://localhost:8080

servilo respondas:

Hello World!

4) El la dosierujo, kie vi elŝutis la specimenan kodon, iru al la dosierujo kiu enhavas loadgen:

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

5) Kreu la sekvajn mediajn variablojn:

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

6) Lanĉo virtualenv:

virtualenv --python python3 env

7) Aktivigu la virtualan medion:

source env/bin/activate

8) Fiksu postulojn por loadgen:

pip3 install -r requirements.txt

9) Lanĉo loadgen:

python3 loadgen.py

Ĉe ekfunkciigo loadgen montras ion kiel la sekvan mesaĝon:

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

En alia fina fenestro servilo eligas la sekvajn mesaĝojn al la konzolo:

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

De interreta perspektivo, la tuta aplikaĵo funkcias per ununura gastiganto (loka komputilo aŭ Cloud Shell virtuala maŝino). Tial vi povas uzi localhostsendi petojn al servilo.
10) Ĉesi loadgen и servilo, eniru Ctrl-c en ĉiu fina fenestro.
11) En la fina fenestro loadgen malaktivigu la virtualan medion:

deactivate

Pakado de aplikaĵo en ujoj

Por ruli la aplikaĵon sur GKE, vi devas paki la ekzemplan aplikaĵon − servilo и loadgen - en ujoj. Ujo estas maniero paki aplikaĵon por izoli ĝin de ĝia medio.

Por paki aplikaĵon en ujon, vi bezonas dockerfile. dockerfile estas tekstdosiero kiu difinas komandojn por konstrui la fontkodon de la aplikaĵo kaj ĝiajn dependecojn enen Docker-bildo. Fojo konstruita, vi alŝutas la bildon al ujo-registro kiel Docker Hub aŭ Uja Registro.

La ekzemplo jam havas dockerfile por servilo и loadgen kun ĉiuj necesaj komandoj por kolekti bildojn. Malsupre - dockerfile por servilo:

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" ]

  • teamo DE python:3-svelta kiel bazo diras al Docker uzi la plej novan Bildo de Python 3 kiel bazo.
  • teamo KOPIO. . kopias la fontdosierojn al la nuna labordosierujo (nur en nia kazo servilo.py) al la dosiersistemo de la ujo.
  • ENIRPUNTO difinas la komandon kiu estas uzata por komenci la ujon. En nia kazo, ĉi tiu komando estas preskaŭ la sama kiel tiu, kiun vi kutimis ruli servilo.py el fontkodo.
  • teamo EKPONI indikas tion servilo atendas datumojn tra la haveno 8080. Ĉi tiu teamo ne estas provizas havenojn. Ĉi tio estas ia dokumentado necesa por malfermi la havenon 8080 kiam oni komencas la ujon.

Preparante enhavigi vian aplikaĵon

1) Agordu la sekvajn mediajn variablojn. Anstataŭigi PROJECT_ID al via GCP-projekta ID.

export PROJECT_ID="PROJECT_ID"

export GCR_REPO="preparing-istio"

Uzante valorojn PROJECT_ID и GCR_REPO vi etikedas la Docker-bildon kiam vi konstruas ĝin kaj puŝas ĝin al privata Uja Registro.

2) Agordu la defaŭltan GCP-projekton por la komandlinia ilo gcloud.

gcloud config set project $PROJECT_ID

3) Agordu la defaŭltan zonon por la komandlinia ilo gcloud.

gcloud config set compute/zone us-central1-b

4) Certiĝu, ke la Servo de Container Registry estas ebligita en la GCP-projekto.

gcloud services enable containerregistry.googleapis.com

Konteniga servilo

  1. Iru al la dosierujo kie troviĝas la ekzemplo servilo:

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

  2. Kunvenu la bildon uzante dockerfile kaj la mediaj variabloj, kiujn vi difinis pli frue:

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

Parametro -t reprezentas la Docker-etikedon. Ĉi tiu estas la nomo de la bildo, kiun vi uzas dum disfaldi la ujon.

  1. Alŝutu la bildon al la Uja Registro:
    docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

Kontenigo de loadgen

1) Iru al la dosierujo kie troviĝas la ekzemplo loadgen:

cd ../loadgen

2) Kolektu la bildon:

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

3) Alŝutu la bildon al la Uja Registro:

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

Vidu liston de bildoj

Revizu la liston de bildoj en la deponejo kaj kontrolu, ke la bildoj estas alŝutitaj:

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

La komando montras la nomojn de la lastatempe alŝutitaj bildoj:

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

Kreante GKE-grupon.

Ĉi tiuj ujoj povus ruliĝi sur virtuala maŝino de Cloud Shell aŭ en komputilo kun la komando Docker kuri. Sed en produktadmedio, vi bezonas manieron centre reĝisori ujojn. Ekzemple, vi bezonas sistemon, kiu certigas, ke ujoj ĉiam funkcias, kaj vi bezonas manieron pligrandigi kaj ŝpruci pliajn ujojn se trafiko pliiĝas.

Por ruli konteneritajn aplikojn vi povas uzi G.K.E.. GKE estas kontenera orkestra platformo, kiu kunigas virtualajn maŝinojn en areton. Ĉiu virtuala maŝino estas nomita nodo. GKE-grupoj baziĝas sur la malfermfonta Kubernetes-grupo-administra sistemo. Kubernetes disponigas mekanismojn por interagado kun la areto.

Kreante GKE-grupon:

1) Kreu areton:

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

teamo gcloud kreas jam pretan areton en la GCP-projekto kaj defaŭlta zono, kiujn vi specifis. Por ruli Istio, ni rekomendas havi almenaŭ 4 nodojn kaj virtualan maŝinon n1-normo-2.

La teamo kreas la areton en kelkaj minutoj. Kiam la areto estas preta, la komando eligas ion tian сообщение.

2) Provizu akreditaĵojn en la komandlinia ilo kubectluzi ĝin por administri la areton:

gcloud container clusters get-credentials istioready

3) Nun vi povas komuniki kun Kubernetes per kubectl. Ekzemple, la sekva komando povas ekscii la staton de nodoj:

kubectl get nodes

La komando produktas liston de nodoj:

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

Ŝlosilaj Konceptoj de Kubernetes

La diagramo montras aplikaĵon pri GKE:

Preparante aplikaĵon por Istio

Antaŭ ol vi deplojos ujojn en GKE, lernu la ĉefajn konceptojn de Kubernetes. Estas ligiloj ĉe la fino se vi volas lerni pli.

  • Nodoj kaj aretoj. En GKE, nodo estas virtuala maŝino. Sur aliaj Kubernetes-platformoj, nodo povas esti komputilo aŭ virtuala maŝino. Areto estas kolekto de nodoj, kiuj povas esti konsiderataj kiel ununura unuo, kie vi deplojas kontenerigitan aplikaĵon.
  • Pods. En Kubernetes, ujoj funkcias en guŝoj. Pod en Kubernetes estas nedividebla unuo. Pod tenas unu aŭ plurajn ujojn. Vi deplojas servilujojn kaj loadgen en apartaj balgoj. Kiam estas pluraj ujoj en pod (ekzemple, aplika servilo kaj prokura servilo), ujoj estas administritaj kiel ununura unuo kaj kunhavas podresursojn.
  • Deplojoj. En Kubernetes, deplojo estas objekto, kiu estas kolekto de identaj podoj. Deplojo lanĉas multoblajn kopiojn de balgoj distribuitaj tra aretnodoj. Deplojo aŭtomate anstataŭigas podojn kiuj malsukcesis aŭ ne respondas.
  • Kubernetes servo. Kiam vi ruliĝas aplikaĵokodo en GKE, la rilato inter loadgen и servilo. Kiam vi komencis servojn en virtuala maŝino aŭ labortablo de Cloud Shell, vi sendis petojn al servilo per la adreso localhost: 8080. Post kiam deplojitaj al GKE, podoj estas ekzekutitaj sur disponeblaj nodoj. Defaŭlte, vi ne havas kontrolon pri kiu nodo funkcias la podo, do vi balgoj neniuj konstantaj IP-adresoj.
    Por akiri IP-adreson por servilo, vi devas difini retan abstraktadon supre de la podoj. Jen kio ĝi estas Kubernetes servo. La Kubernetes-servo disponigas konstantan finpunkton por aro da podoj. Estas kelkaj specoj de servoj. servilo uzoj LoadBalancer, kiu provizas eksteran IP-adreson por kontakti servilo de ekster la areto.
    Kubernetes ankaŭ havas enkonstruitan DNS-sistemon kiu asignas DNS-nomojn (ekzemple, helloserver.default.cluster.local) servoj. Dank' al tio, podoj ene de la areto komunikas kun aliaj podoj en la areto ĉe konstanta adreso. La DNS-nomo ne povas esti uzata ekster la areto, kiel en Cloud Shell aŭ en komputilo.

Kubernetes manifestiĝas

Kiam vi prizorgis la aplikaĵon de fonto, vi uzis la imperativan komandon python3

servilo.py

Imperativo implicas verbon: "faru ĉi tion."

Kubernetes uzas deklara modelo. Ĉi tio signifas, ke ni ne diras al Kubernetes precize kion fari, sed prefere priskribas la deziratan staton. Ekzemple, Kubernetes startas kaj haltigas podojn laŭbezone por konservi la realan staton de la sistemo kongrua kun la dezirata stato.

Vi indikas la deziratan staton en manifestoj aŭ dosieroj YAML. YAML-dosiero enhavas specifojn por unu aŭ pluraj Kubernetes-objektoj.

La ekzemplo enhavas YAML-dosieron por servilo и loadgen. Ĉiu YAML-dosiero specifas la deziratan staton de la deploja objekto kaj Kubernetes-servo.

servilo.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

  • speco indikas la tipon de la objekto.
  • metadatenoj.nomo specifas la disfaldan nomon.
  • Unua kampo spec enhavas priskribon de la dezirata stato.
  • spec.replicas indikas la deziratan nombron da balgoj.
  • Sekcio spec.ŝablono difinas pod-ŝablonon. Estas kampo en la podspecifo bildo, kiu specifas la nomon de la bildo, kiu devas esti eltirita el la Uja Registro.

La servo estas difinita jene:

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

  • LoadBalancer: Klientoj sendas petojn al la IP-adreso de la ŝarĝbalancilo, kiu havas konstantan IP-adreson kaj estas alirebla de ekster la areto.
  • celPorto: kiel vi memoras, la teamo EKPONI 8080 в dockerfile ne disponigis havenojn. Vi provizas la havenon 8080por ke vi povu kontakti la ujon servilo ekster la areto. En nia kazo hellosvc.default.cluster.local:80 (mallonga nomo: hellosvc) respondas al la haveno 8080 Pod IP-adresoj salutservilo.
  • haveno: Ĉi tiu estas la havennumero kie aliaj servoj en la areto sendos petojn.

loadgen.yaml

Deplojo objekto al loadgen.yaml aspekti kiel servilo.yaml. La diferenco estas, ke la deploja objekto enhavas sekcion env. Ĝi difinas la mediovariablojn kiuj estas bezonataj loadgen kaj kiun vi instalis dum rulado de la aplikaĵo el la fonto.

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

Tempo loadgen ne akceptas alvenantajn petojn, por la kampo tipo indikis ClusterIP. Ĉi tiu tipo disponigas konstantan IP-adreson, kiun servoj en la areto povas uzi, sed ĉi tiu IP-adreso ne estas elmontrita al eksteraj klientoj.

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

Deplojante Ujojn en GKE

1) Iru al la dosierujo kie troviĝas la ekzemplo servilo:

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

2) Malfermu servilo.yaml en tekstredaktilo.
3) Anstataŭigu la nomon en la kampo bildo al la nomo de via Docker-bildo.

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

Anstataŭigi PROJECT_ID al via GCP-projekta ID.
4) Konservu kaj fermu servilo.yaml.
5) Deploji la YAML-dosieron al Kubernetes:

kubectl apply -f server.yaml

Post sukcesa kompletigo, la komando produktas la sekvan kodon:

deployment.apps/helloserver created
service/hellosvc created

6) Iru al la dosierujo kie loadgen:

cd ../loadgen

7) Malfermu loadgen.yaml en tekstredaktilo.
8) Anstataŭigu la nomon en la kampo bildo al la nomo de via Docker-bildo.

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

Anstataŭigi PROJECT_ID al via GCP-projekta ID.
9) Konservu kaj fermu loadgen.yaml, fermu la tekstredaktilon.
10) Deploji la YAML-dosieron al Kubernetes:

kubectl apply -f loadgen.yaml

Post sukcesa kompletigo, la komando produktas la sekvan kodon:

deployment.apps/loadgenerator created
service/loadgensvc created

11) Kontrolu la staton de la podoj:

kubectl get pods

La komando montras la staton:

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

12) Eltiru aplikaĵajn protokolojn el la pod loadgen. Anstataŭigi POD_ID al la ID de la antaŭa respondo.

kubectl logs loadgenerator-POD_ID

13) Akiru eksterajn IP-adresojn hellosvc:

kubectl get service

La komanda respondo aspektas kiel ĉi tio:

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) Sendu peton al hellosvc: anstataŭi EXTERNAL_IP al ekstera IP-adreso hellosvc.

curl http://EXTERNAL_IP

Ni alprenu Istion

Vi jam havas aplikaĵon deplojitan al GKE. loadgen povas uzi Kubernetes DNS (hellosvc:80) por sendi petojn al servilokaj vi povas sendi petojn al servilo per ekstera IP-adreso. Kvankam Kubernetes havas multajn funkciojn, mankas iuj informoj pri la servoj:

  • Kiel la servoj interagas? Kio estas la rilatoj inter servoj? Kiel fluas trafiko inter servoj? Ĉu vi konscias tion loadgen sendas petojn al servilo, sed imagu, ke vi scias nenion pri la aplikaĵo. Por respondi ĉi tiujn demandojn, ni rigardu la liston de kurantaj podoj en GKE.
  • Metriko. Kiel longe servilo respondas al envenanta peto? Kiom da petoj sekundo ricevas la servilo? Ĉu ĝi donas erarmesaĝojn?
  • Sekurecaj Informoj. Trafiko inter loadgen и servilo nur trapasas HTTP aŭ de mTLS?

Istio respondas ĉiujn ĉi tiujn demandojn. Por fari tion, Istio metas kromprokurilon sendita en ĉiu balgo. La Envoy-prokurilo kaptas ĉiun envenantan kaj elirantan trafikon al aplikaj ujoj. Ĝi signifas tion servilo и loadgen ricevi per sidecar prokurilo Envoy, kaj la tutan trafikon de loadgen к servilo trairas la Envoy-prokurilon.

Konektoj inter Envoy-prokuriloj formas servoreton. La serva mesh-arkitekturo disponigas tavolon de kontrolo supre de Kubernetes.

Preparante aplikaĵon por Istio

Ĉar Envoy-prokuriloj funkcias en siaj propraj ujoj, Istio povas esti instalita supre de GKE-areto kun preskaŭ neniuj ŝanĝoj al la aplika kodo. Sed vi faris iom da laboro por prepari vian aplikaĵon por esti administrita de Istio:

  • Servoj por ĉiuj ujoj. Al deplojoj servilo и loadgen ligita al la servo Kubernetes. Eĉ loadgen, kiu ne ricevas alvenantajn petojn, ekzistas servo.
  • Havenoj en servoj devas havi nomojn. Kvankam servaj havenoj povas esti lasitaj sennomaj en GKE, Istio postulas, ke vi specifu havenonomo konforme al lia protokolo. En la YAML-dosiero la haveno por servilo vokis Httpĉar servilo uzas la protokolon HTTP. Se servo uzata gRPC, vi nomus la havenon grpc.
  • Deplojoj estas markitaj. Sekve, vi povas uzi la trafikadministrajn funkciojn de Istio, kiel disigi trafikon inter versioj de la sama servo.

Instalado

Estas du manieroj instali Istio. Povas ebligu Istio sur GKE-etendoinstalu la malfermfontan version de Istio sur la areto. Kun Istio sur GKE, vi povas facile administri Istio-instalaĵojn kaj ĝisdatigojn dum la GKE-clustervivociklo. Se vi volas la plej novan version de Istio aŭ pli da kontrolo de via kontrolpanela agordo de Istio, instalu la malfermfontan version anstataŭ la etendo Istio sur GKE. Por decidi pri la aliro, legu la artikolon Ĉu mi bezonas Istio sur GKE?.

Elektu opcion, legu la taŭgan gvidilon kaj sekvu la instrukciojn por instali Istio sur via areto. Se vi volas uzi Istio kun via lastatempe deplojita aplikaĵo, ebligi sidecar efektivigo por nomspaco defaŭlte.

Очистка

Por eviti esti ŝargita al via konto de Google Cloud Platform por la rimedoj, kiujn vi uzis en ĉi tiu lernilo, forigu la konteneron post kiam vi instalis Istio kaj ludis kun la ekzempla aplikaĵo. Ĉi tio forigos ĉiujn amasajn rimedojn, kiel komputikazojn, diskojn kaj retajn rimedojn.

Kio sekvas?

fonto: www.habr.com

Aldoni komenton