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:
Lernante simplan salutan mondon-aplikaĵon kun pluraj servoj.
Rulu la aplikaĵon de fontkodo.
Pakado de la aplikaĵo en ujoj.
Kreante Kubernetes-grupon.
Deplojante ujojn en areton.
Antaŭ ol komenci
Sekvu la instrukciojn por ebligi la Kubernetes Engine API:
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.
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.
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
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.
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.
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:
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:
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.
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.
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.
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.
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.
Ĉ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-etendo aŭ instalu 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.