Utarbeide en søknad for Istio

Utarbeide en søknad for Istio

Istio er et praktisk verktøy for å koble til, sikre og overvåke distribuerte applikasjoner. Istio bruker en rekke teknologier for å kjøre og administrere programvare i stor skala, inkludert containere for å pakke applikasjonskode og avhengigheter for distribusjon, og Kubernetes for å administrere disse containerne. For å jobbe med Istio må du derfor vite hvordan en applikasjon med flere tjenester basert på disse teknologiene fungerer без Istio. Hvis disse verktøyene og konseptene allerede er kjent for deg, kan du gjerne hoppe over denne opplæringen og gå rett til delen Installere Istio på Google Kubernetes Engine (GKE) eller installere en utvidelse Istio på GKE.

Dette er en trinn-for-trinn-guide hvor vi vil gå gjennom hele prosessen fra kildekode til GKE-beholder for å gi deg en grunnleggende forståelse av disse teknologiene gjennom et eksempel. Du vil også se hvordan Istio utnytter kraften til disse teknologiene. Dette forutsetter at du ikke vet noe om containere, Kubernetes, servicemasker eller Istio.

oppgaver

I denne opplæringen skal du fullføre følgende oppgaver:

  1. Lær en enkel hei verden-applikasjon med flere tjenester.
  2. Kjør programmet fra kildekoden.
  3. Pakke søknaden i beholdere.
  4. Opprette en Kubernetes-klynge.
  5. Utplassering av containere i en klynge.

Før du begynner

Følg instruksjonene for å aktivere Kubernetes Engine API:

  1. Gå til Kubernetes Engine-side i Google Cloud Platform-konsollen.
  2. Opprett eller velg et prosjekt.
  3. Vent til API og relaterte tjenester er aktivert. Dette kan ta et par minutter.
  4. Sørg for at fakturering er konfigurert for Google Cloud Platform-prosjektet ditt. Finn ut hvordan du aktiverer fakturering.

I denne opplæringen kan du bruke Cloud Shell, som forbereder den virtuelle maskinen g1-small i Google Compute Engine med Debian-basert Linux, eller en Linux- eller macOS-datamaskin.

Alternativ A: Bruke Cloud Shell

Fordeler med å bruke Cloud Shell:

  • Python 2 og Python 3 utviklingsmiljøer (inkludert virtualenv) er fullt konfigurert.
  • Kommandolinjeverktøy gcloud, Docker, git и kubectl, som vi skal bruke, er allerede installert.
  • Du har flere å velge mellom tekstredigerere:
    1. Kode editor, som åpnes med redigeringsikonet øverst i Cloud Shell-vinduet.
    2. Emacs, Vim eller Nano, som åpnes fra kommandolinjen i Cloud Shell.

Å bruke Cloud Shell:

  1. Gå til GCP-konsollen.
  2. Klikk på knappen Aktiver Cloud Shell (Aktiver Cloud Shell) øverst i GCP-konsollvinduet.

Utarbeide en søknad for Istio

I nedre del GCP-konsoll En Cloud Shell-økt med en kommandolinje åpnes i et nytt vindu.

Utarbeide en søknad for Istio

Alternativ B: Bruke kommandolinjeverktøy lokalt

Hvis du skal jobbe på en datamaskin som kjører Linux eller macOS, må du konfigurere og installere følgende komponenter:

  1. Tilpass Python 3 og Python 2 utviklingsmiljø.

  2. Installer Cloud SDK med kommandolinjeverktøy gcloud.

  3. Satt kubectl - kommandolinjeverktøy for å jobbe med Kubernetes.

    gcloud components install kubectl

  4. Satt Docker Community Edition (CE). Du vil bruke kommandolinjeverktøyet Dockerfor å lage beholderbilder for eksempelapplikasjonen.

  5. Installer verktøyet Git versjonskontrollfor å få prøveapplikasjonen fra GitHub.

Last ned eksempelkode

  1. Last ned kildekoden hei server:

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

  2. Gå til eksempelkodekatalogen:

    cd istio-samples/sample-apps/helloserver

Utforske en applikasjon med flere tjenester

Eksempelapplikasjonen er skrevet i Python og består av to komponenter som samhandler vha REST:

  • server: enkel server med ett endepunkt FÅ, /, som skriver ut "hello world" til konsollen.
  • loadgen: skript som sender trafikk til server, med et konfigurerbart antall forespørsler per sekund.

Utarbeide en søknad for Istio

Kjøre et program fra kildekoden

For å utforske eksempelapplikasjonen, kjør den i Cloud Shell eller på datamaskinen din.
1) I katalogen istio-samples/sample-apps/helloserver løpe server:

python3 server/server.py

Ved oppstart server følgende vises:

INFO:root:Starting server...

2) Åpne et annet terminalvindu for å sende forespørsler til server. Hvis du bruker Cloud Shell, klikker du på legg til-ikonet for å åpne en ny økt.
3) Send en forespørsel til server:

curl http://localhost:8080

server svarer:

Hello World!

4) Fra katalogen der du lastet ned eksempelkoden, gå til katalogen som inneholder loadgen:

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

5) Lag følgende miljøvariabler:

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

6) Lansering virtualenv:

virtualenv --python python3 env

7) Aktiver det virtuelle miljøet:

source env/bin/activate

8) Still krav til loadgen:

pip3 install -r requirements.txt

9) Lansering loadgen:

python3 loadgen.py

Ved oppstart loadgen viser noe sånt som følgende melding:

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

I et annet terminalvindu server sender ut følgende meldinger til konsollen:

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

Fra et nettverksperspektiv kjører hele applikasjonen på en enkelt vert (lokal datamaskin eller Cloud Shell virtuell maskin). Derfor kan du bruke localhostå sende forespørsler til server.
10) Å stoppe loadgen и server, Tast inn Ctrl-c i hvert terminalvindu.
11) I terminalvinduet loadgen deaktiver det virtuelle miljøet:

deactivate

Pakke en applikasjon i containere

For å kjøre applikasjonen på GKE, må du pakke eksempelapplikasjonen − server и loadgen - inn Containere. En beholder er en måte å pakke en applikasjon for å isolere den fra miljøet.

For å pakke en applikasjon inn i en beholder, trenger du Dockerfile. Dockerfile er en tekstfil som definerer kommandoer for å bygge applikasjonens kildekode og dens avhengigheter inn i Docker-bilde. Når det er bygget, laster du opp bildet til et containerregister som Docker Hub eller Beholderregister.

Eksemplet har allerede Dockerfile for server и loadgen med alle nødvendige kommandoer for å samle bilder. Nedenfor - Dockerfile for 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/*

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

  • Lag FRA python:3-slank som base ber Docker om å bruke det siste Python 3 bilde som en base.
  • Lag KOPIERE. . kopierer kildefilene til gjeldende arbeidskatalog (bare i vårt tilfelle server.py) til beholderens filsystem.
  • INNGANGSPUNKT definerer kommandoen som brukes til å starte beholderen. I vårt tilfelle er denne kommandoen nesten den samme som den du pleide å kjøre server.py fra kildekoden.
  • Lag AVDEKKE indikerer det server venter på data gjennom porten 8080. Dette laget er ikke gir havner. Dette er en slags dokumentasjon som trengs for å åpne porten 8080 når du starter beholderen.

Forbereder på å containerisere søknaden din

1) Angi følgende miljøvariabler. Erstatte PROJECT_ID til GCP-prosjekt-ID-en din.

export PROJECT_ID="PROJECT_ID"

export GCR_REPO="preparing-istio"

Bruke verdier PROJECT_ID и GCR_REPO du merker Docker-bildet når du bygger det og skyver det til et privat containerregister.

2) Angi standard GCP-prosjekt for kommandolinjeverktøyet gcloud.

gcloud config set project $PROJECT_ID

3) Angi standardsonen for kommandolinjeverktøyet gcloud.

gcloud config set compute/zone us-central1-b

4) Sørg for at Container Registry-tjenesten er aktivert i GCP-prosjektet.

gcloud services enable containerregistry.googleapis.com

Containeriseringsserver

  1. Gå til katalogen der eksemplet ligger server:

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

  2. Sett sammen bildet ved hjelp av Dockerfile og miljøvariablene du definerte tidligere:

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

Parameter -t representerer Docker-taggen. Dette er navnet på bildet du bruker når du distribuerer beholderen.

  1. Last opp bildet til containerregisteret:
    docker push gcr.io/$PROJECT_ID/$GCR_REPO/helloserver:v0.0.1

Containerisering av loadgen

1) Gå til katalogen der eksemplet ligger loadgen:

cd ../loadgen

2) Samle bildet:

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

3) Last opp bildet til containerregisteret:

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

Se en liste over bilder

Se gjennom listen over bilder i depotet og kontroller at bildene er lastet opp:

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

Kommandoen viser navnene på de nylig opplastede bildene:

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

Opprette en GKE-klynge.

Disse beholderne kan kjøres på en Cloud Shell virtuell maskin eller på en datamaskin med kommandoen docker kjøre. Men i et produksjonsmiljø trenger du en måte å sentralt orkestrere containere. Du trenger for eksempel et system som sørger for at containere alltid kjører, og du trenger en måte å skalere opp og spinne opp flere containerforekomster på hvis trafikken øker.

For å kjøre containeriserte applikasjoner kan du bruke G.K.E.. GKE er en containerorkestreringsplattform som samler virtuelle maskiner til en klynge. Hver virtuell maskin kalles en node. GKE-klynger er basert på åpen kildekode Kubernetes klyngestyringssystem. Kubernetes gir mekanismer for å samhandle med klyngen.

Opprette en GKE-klynge:

1) Opprett en klynge:

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

Lag gcloud oppretter en istioready-klynge i GCP-prosjektet og standardsonen du spesifiserte. For å kjøre Istio anbefaler vi å ha minst 4 noder og en virtuell maskin n1-standard-2.

Teamet oppretter klyngen på noen få minutter. Når klyngen er klar, vil kommandoen gi noe sånt som dette сообщение.

2) Oppgi legitimasjon i kommandolinjeverktøyet kubectlfor å bruke den til å administrere klyngen:

gcloud container clusters get-credentials istioready

3) Nå kan du kommunisere med Kubernetes via kubectl. For eksempel kan følgende kommando finne ut statusen til noder:

kubectl get nodes

Kommandoen produserer en liste over noder:

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 nøkkelkonsepter

Diagrammet viser en applikasjon på GKE:

Utarbeide en søknad for Istio

Før du distribuerer containere i GKE, lær deg nøkkelkonseptene til Kubernetes. Det er lenker helt på slutten hvis du vil lære mer.

  • Noder og klynger. I GKE er en node en virtuell maskin. På andre Kubernetes-plattformer kan en node være en datamaskin eller en virtuell maskin. En klynge er en samling av noder som kan betraktes som en enkelt enhet der du distribuerer en containerisert applikasjon.
  • Pods. I Kubernetes kjører containere i belg. En Pod i Kubernetes er en udelelig enhet. En Pod har en eller flere beholdere. Du distribuerer servercontainere og loadgen i separate belg. Når det er flere beholdere i en pod (for eksempel en applikasjonsserver og proxy-server), beholdere administreres som en enkelt enhet og deler pod-ressurser.
  • Implementeringer. I Kubernetes er en distribusjon et objekt som er en samling av identiske pods. Implementering lanserer flere replikaer av pods fordelt på klyngenoder. Implementering erstatter automatisk pods som har mislyktes eller ikke svarer.
  • Kubernetes tjeneste. Når du kjører applikasjonskode i GKE, er forbindelsen mellom loadgen и server. Når du startet tjenester på en Cloud Shell virtuell maskin eller skrivebord, sendte du forespørsler til server ved localhost: 8080. Når de er distribuert til GKE, kjøres pods på tilgjengelige noder. Som standard har du ingen kontroll over hvilken node poden kjører på, så du belger ingen permanente IP-adresser.
    For å få en IP-adresse for server, må du definere en nettverksabstraksjon på toppen av podene. Det er det det er Kubernetes tjeneste. Kubernetes-tjenesten gir et vedvarende endepunkt for et sett med pods. Det er noen få typer tjenester. server bruker LoadBalancer, som gir en ekstern IP-adresse å kontakte server fra utenfor klyngen.
    Kubernetes har også et innebygd DNS-system som tildeler DNS-navn (f.eks. helloserver.default.cluster.local) tjenester. Takket være dette kommuniserer poder i klyngen med andre poder i klyngen på en permanent adresse. DNS-navnet kan ikke brukes utenfor klyngen, for eksempel i Cloud Shell eller på en datamaskin.

Kubernetes manifesterer seg

Når du kjørte programmet fra kilden, brukte du imperative kommandoen python3

server.py

Imperativ innebærer et verb: "gjør dette."

Kubernetes bruker deklarativ modell. Dette betyr at vi ikke forteller Kubernetes nøyaktig hva de skal gjøre, men heller beskriver ønsket tilstand. For eksempel starter og stopper Kubernetes pods etter behov for å sikre at den faktiske tilstanden til systemet samsvarer med ønsket tilstand.

Du angir ønsket tilstand i manifester eller filer YAML. En YAML-fil inneholder spesifikasjoner for ett eller flere Kubernetes-objekter.

Eksemplet inneholder en YAML-fil for server и loadgen. Hver YAML-fil spesifiserer ønsket tilstand for distribusjonsobjektet og Kubernetes-tjenesten.

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

  • slag angir typen av objektet.
  • metadata.navn angir distribusjonsnavnet.
  • Første felt spec inneholder en beskrivelse av ønsket tilstand.
  • spes.replikaer indikerer ønsket antall pods.
  • Seksjon spec.mal definerer en pod-mal. Det er et felt i pod-spesifikasjonen bilde, som spesifiserer navnet på bildet som må trekkes ut fra containerregisteret.

Tjenesten er definert som følger:

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

  • LoadBalancer: Klienter sender forespørsler til IP-adressen til lastbalanseren, som har en vedvarende IP-adresse og er tilgjengelig fra utenfor klyngen.
  • targetPort: som du husker, laget UTSTILL 8080 в Dockerfile ga ikke porter. Du oppgir porten 8080slik at du kan kontakte containeren server utenfor klyngen. I vårt tilfelle hellosvc.default.cluster.local:80 (kort navn: hellosvc) tilsvarer porten 8080 Pod IP-adresser hei server.
  • havn: Dette er portnummeret der andre tjenester i klyngen vil sende forespørsler.

loadgen.yaml

Distribusjonsobjekt til loadgen.yaml ser ut som server.yaml. Forskjellen er at distribusjonsobjektet inneholder en seksjon env. Den definerer miljøvariablene som er nødvendige loadgen og som du installerte når du kjørte programmet fra kilden.

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

En gang loadgen godtar ikke innkommende forespørsler for feltet typen ukjent ClusterIP. Denne typen gir en vedvarende IP-adresse som tjenester i klyngen kan bruke, men denne IP-adressen er ikke eksponert for eksterne klienter.

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

Utplassering av containere i GKE

1) Gå til katalogen der eksemplet ligger server:

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

2) Åpne server.yaml i et tekstredigeringsprogram.
3) Erstatt navnet i feltet bilde til navnet på Docker-bildet ditt.

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

Erstatte PROJECT_ID til GCP-prosjekt-ID-en din.
4) Lagre og lukk server.yaml.
5) Distribuer YAML-filen til Kubernetes:

kubectl apply -f server.yaml

Etter vellykket fullføring produserer kommandoen følgende kode:

deployment.apps/helloserver created
service/hellosvc created

6) Gå til katalogen hvor loadgen:

cd ../loadgen

7) Åpne loadgen.yaml i et tekstredigeringsprogram.
8) Erstatt navnet i feltet bilde til navnet på Docker-bildet ditt.

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

Erstatte PROJECT_ID til GCP-prosjekt-ID-en din.
9) Lagre og lukk loadgen.yaml, lukk tekstredigeringsprogrammet.
10) Distribuer YAML-filen til Kubernetes:

kubectl apply -f loadgen.yaml

Etter vellykket fullføring produserer kommandoen følgende kode:

deployment.apps/loadgenerator created
service/loadgensvc created

11) Sjekk statusen til podene:

kubectl get pods

Kommandoen viser status:

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

12) Trekk ut applikasjonslogger fra poden loadgen. Erstatte POD_ID til identifikatoren fra forrige svar.

kubectl logs loadgenerator-POD_ID

13) Skaff eksterne IP-adresser hellosvc:

kubectl get service

Kommandoresponsen ser omtrent slik ut:

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) Send en forespørsel til hellosvc: erstatte EXTERNAL_IP til ekstern IP-adresse hellosvc.

curl http://EXTERNAL_IP

La oss ta på Istio

Du har allerede en applikasjon distribuert til GKE. loadgen kan bruke Kubernetes DNS (hellosvc:80) for å sende forespørsler til serverog du kan sende forespørsler til server etter ekstern IP-adresse. Selv om Kubernetes har mange funksjoner, mangler det noe informasjon om tjenestene:

  • Hvordan samhandler tjenester? Hva er relasjonene mellom tjenestene? Hvordan flyter trafikken mellom tjenestene? Er du klar over det loadgen sender forespørsler til server, men tenk deg at du ikke vet noe om applikasjonen. For å svare på disse spørsmålene, la oss se på listen over løpende pods i GKE.
  • Beregninger. Hvor lenge server svarer på en innkommende forespørsel? Hvor mange forespørsler per sekund mottas av serveren? Gir den feilmeldinger?
  • Sikkerhetsinformasjon. Trafikk mellom loadgen и server bare går gjennom HTTP eller av mTLS?

Istio svarer på alle disse spørsmålene. For å gjøre dette, plasserer Istio en sidevogn-proxy Envoy i hver pod. Envoy-proxyen fanger opp all innkommende og utgående trafikk til applikasjonsbeholdere. Det betyr at server и loadgen motta via sidevogn proxy Envoy, og all trafikk fra loadgen к server går gjennom envoy proxy.

Forbindelser mellom envoy-fullmakter danner et servicenettverk. Tjenestenett-arkitekturen gir et lag med kontroll på toppen av Kubernetes.

Utarbeide en søknad for Istio

Siden Envoy-proxyer kjører i sine egne containere, kan Istio installeres på toppen av en GKE-klynge med nesten ingen endringer i applikasjonskoden. Men du har gjort litt arbeid for å gjøre applikasjonen klar til å bli administrert av Istio:

  • Tjenester for alle containere. Til utplasseringer server и loadgen knyttet til Kubernetes-tjenesten. Til og med loadgen, som ikke mottar innkommende forespørsler, er det en tjeneste.
  • Porter i tjenester må ha navn. Selv om tjenesteporter kan stå uten navn i GKE, krever Istio at du spesifiserer portnavn i samsvar med hans protokoll. I YAML-filen porten for server kalt httpfordi serveren bruker protokollen HTTP. Hvis tjeneste brukt gRPC, vil du navngi porten grpc.
  • Implementeringer er flagget. Derfor kan du bruke Istios trafikkstyringsfunksjoner, som å dele trafikk mellom versjoner av samme tjeneste.

Installerer Istio

Det er to måter å installere Istio på. Kan aktiver Istio på GKE-utvidelsen eller installer åpen kildekode-versjon av Istio på klyngen. Med Istio på GKE kan du enkelt administrere Istio-installasjoner og oppgraderinger gjennom hele GKE-klyngens livssyklus. Hvis du vil ha den nyeste versjonen av Istio eller mer kontroll over konfigurasjonen av Istio-kontrollpanelet, installer åpen kildekode-versjonen i stedet for Istio on GKE-utvidelsen. For å bestemme tilnærmingen, les artikkelen Trenger jeg Istio på GKE?.

Velg et alternativ, se gjennom den aktuelle veiledningen og følg instruksjonene for å installere Istio på klyngen din. Hvis du ønsker å bruke Istio med din nylig distribuerte applikasjon, aktiver sidevognimplementering for navneområde standard~~POS=TRUNC.

rengjøring

For å unngå å bli belastet Google Cloud Platform-kontoen din for ressursene du brukte i denne opplæringen, slett containerklyngen når du har installert Istio og spilt med eksempelapplikasjonen. Dette vil fjerne alle klyngeressurser, for eksempel dataforekomster, disker og nettverksressurser.

Hva blir det neste?

Kilde: www.habr.com

Legg til en kommentar