{"id":32766,"date":"2019-10-31T21:48:48","date_gmt":"2019-10-31T18:48:48","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1\/"},"modified":"2019-10-31T21:48:48","modified_gmt":"2019-10-31T18:48:48","slug":"kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","title":{"rendered":"Hvordan man starter Istio ved hj\u00e6lp af Kubernetes i produktion. Del 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Hvad er Istio<\/a><\/noindex>? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e. \u041c\u044b \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u0435\u043c \u0432\u0435\u0441\u044c \u0438\u043b\u0438 \u0447\u0430\u0441\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0441 \u043d\u0438\u043c. \u041a\u0430\u043a\u043e\u0439 \u0438\u043c\u0435\u043d\u043d\u043e? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0435\u043b\u0430\u0435\u043c \u0443\u043c\u043d\u044b\u0439 \u0440\u043e\u0443\u0442\u0438\u043d\u0433, \u0438\u043b\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434 circuit breaker, \u043c\u043e\u0436\u0435\u043c \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u00abcanary deployment\u00bb, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043d\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u0430, \u0430 \u043c\u043e\u0436\u0435\u043c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0432\u0430\u0442\u044c \u0432\u043d\u0435\u0448\u043d\u0438\u0435 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u0438 \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432\u0441\u0435 \u043f\u043e\u0445\u043e\u0434\u044b \u0438\u0437 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0432\u043e \u0432\u043d\u0435\u0448\u043d\u044e\u044e \u0441\u0435\u0442\u044c. \u0415\u0441\u0442\u044c \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u044c \u0437\u0430\u0434\u0430\u0432\u0430\u0442\u044c policy \u043f\u0440\u0430\u0432\u0438\u043b\u0430 \u0434\u043b\u044f \u043a\u043e\u043d\u0442\u0440\u043e\u043b\u044f \u043f\u043e\u0445\u043e\u0434\u043e\u0432 \u043c\u0435\u0436\u0434\u0443 \u0440\u0430\u0437\u043d\u044b\u043c\u0438 \u043c\u0438\u043a\u0440\u043e\u0441\u0435\u0440\u0432\u0438\u0441\u0430\u043c\u0438. \u041d\u0430\u043a\u043e\u043d\u0435\u0446, \u043c\u044b \u043c\u043e\u0436\u0435\u043c \u043f\u043e\u043b\u0443\u0447\u0438\u0442\u044c \u0432\u0441\u044e \u043a\u0430\u0440\u0442\u0443 \u0432\u0437\u0430\u0438\u043c\u043e\u0434\u0435\u0439\u0441\u0442\u0432\u0438\u044f \u043f\u043e \u0441\u0435\u0442\u0438 \u0438 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0443\u043d\u0438\u0444\u0438\u0446\u0438\u0440\u043e\u0432\u0430\u043d\u043d\u044b\u0439 \u0441\u0431\u043e\u0440 \u043c\u0435\u0442\u0440\u0438\u043a \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u043f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e \u0434\u043b\u044f \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439.<\/p>\n

Du kan l\u00e6se om mekanismen bag arbejdet i den officielle dokumentation<\/a><\/noindex>. Istio er et virkelig kraftfuldt v\u00e6rkt\u00f8j, der kan l\u00f8se mange opgaver og problemer. I denne artikel vil jeg gerne besvare de vigtigste sp\u00f8rgsm\u00e5l, der ofte opst\u00e5r i starten af arbejdet med Istio. Det vil hj\u00e6lpe dig med at forst\u00e5 det hurtigere.<\/p>\n

\"Hvordan
\n<\/a><\/noindex><\/p>\n

Arbejdets princip<\/h3>\n

\nIstio best\u00e5r af to hovedomr\u00e5der \u2014 kontrolplanet og dataplanet. Kontrolplanet indeholder de vigtigste komponenter, der sikrer korrekt drift af de \u00f8vrige. I den nuv\u00e6rende version (1.0) har kontrolplanet tre hovedkomponenter: Pilot, Mixer, Citadel. Citadel vil vi ikke behandle, det er n\u00f8dvendigt for at generere certifikater til sikring af mutual TLS mellem tjenester.<\/p>\n

\"Hvordan
\n
\nPilot er den prim\u00e6re styringskomponent, der distribuerer al information om, hvad vi har i klyngen \u2013 tjenester, deres endpoints og routingregler (for eksempel regler for Canary deployment eller circuit breaker-regler).<\/p>\n

Mixer er en valgfri komponent i kontrolplanet, der giver mulighed for indsamling af m\u00e5linger, logs og enhver information om netv\u00e6rksinteraktion. Den holder ogs\u00e5 \u00f8je med overholdelsen af politikregler og overholdelsen af rate limits.<\/p>\n

Dataplanet implementeres ved hj\u00e6lp af sidecar proxy-containere. Standard bruges en kraftfuld proxy-server envoy<\/a><\/noindex>. Den kan erstattes af en anden implementering, for eksempel nginx (nginmesh).<\/p>\n

For at Istio skal fungere helt gennemsigtigt for applikationer, findes der et system til automatisk injektion. Den seneste implementering er velegnet til versioner af Kubernetes 1.9+ (mutational admission webhook). For Kubernetes versioner 1.7, 1.8 er der mulighed for at bruge Initializer.<\/p>\n

Sidecar-containere tilsluttes til Pilot via GRPC-protokollen, som muligg\u00f8r optimering af model for push af \u00e6ndringer, der sker i klyngen. GRPC blev brugt i Envoy fra version 1.6, i Istio er det anvendt fra version 0.8 og repr\u00e6senterer pilot-agent \u2014 en wrapper p\u00e5 golang oven p\u00e5 envoy, der konfigurerer opstartparametre.<\/p>\n

Pilot og Mixer er fuldst\u00e6ndig stateless komponenter, alt deres tilstand opbevares i hukommelsen. Konfigurationen for dem angives i form af Kubernetes Custom Resources, som gemmes i etcd.
\nIstio-agenten f\u00e5r adressen til Pilot og \u00e5bner en GRPC-str\u00f8m til den. <\/p>\n

Som jeg allerede har sagt, implementerer Istio al funktionalitet helt gennemsigtigt for applikationer. Lad os finde ud af hvordan. Algoritmen er s\u00e5dan:<\/p>\n

    \n
  1. Vi deployerer en ny version af tjenesten.<\/li>\n
  2. Afh\u00e6ngigt af tilgangen til injecting af sidecar containeren tilf\u00f8jes istio-init containeren og istio-agent containeren (envoy) p\u00e5 tidspunktet for anvendelse af konfigurationen, eller de kan allerede v\u00e6re manuelt indsat i beskrivelsen af Pod enheden i Kubernetes.<\/li>\n
  3. istio-init containeren er et script, der anvender iptables regler for pod'en. Der er to muligheder for at konfigurere indpakningen af trafikken til istio-agent containeren: bruge redirect iptables regler, eller TPROXY<\/a><\/noindex>. P\u00e5 tidspunktet for skrivningen af artiklen anvendes redirect regler som standard. I istio-init er der mulighed for at konfigurere, hvilken trafik der skal fanges og dirigeres til istio-agent. For eksempel, for at fange al indg\u00e5ende og al udg\u00e5ende trafik, skal parametre indstilles -i<\/code> og -b<\/code> til v\u00e6rdien *<\/code>. Man kan angive specifikke porte, der skal fanges. For at undg\u00e5 at fange en bestemt subnet kan den angives ved hj\u00e6lp af flaget -x<\/code>.<\/li>\n
  4. Efter udf\u00f8relsen af init containerne startes de prim\u00e6re, herunder pilot-agent (envoy). Den tilslutter sig allerede implementeret Pilot via GRPC og modtager information om alle eksisterende tjenester og routing politikker i klyngen. Baseret p\u00e5 de modtagne data konfigurerer den klynger og angiver direkte endpoints for vores applikationer i Kubernetes klyngen. Det er ogs\u00e5 vigtigt at bem\u00e6rke et v\u00e6sentligt punkt: envoy konfigurerer dynamisk lyttere (par af IP, port), som den begynder at lytte til. Derfor, n\u00e5r anmodningerne kommer ind i pod'en, omdirigeres de ved hj\u00e6lp af redirect iptables regler til sidecar'en, og envoy kan allerede succesfuldt h\u00e5ndtere disse forbindelser og forst\u00e5, hvor trafikken skal sendes videre. P\u00e5 dette trin sker der ogs\u00e5 en sending af information til Mixer, som vi vil se n\u00e6rmere p\u00e5 senere, og sending af tracing spans.<\/li>\n<\/ol>\n

    \nSom et resultat f\u00e5r vi et helt netv\u00e6rk af envoy proxy-servere, som vi kan konfigurere fra et centralt punkt (Pilot). Alle inbound og outbound anmodninger passerer gennem envoy. Desuden fanges kun TCP trafik. Det betyder, at Kubernetes service IP'en opl\u00f8ses ved hj\u00e6lp af kube-dns over UDP uden \u00e6ndringer. Derefter, efter opl\u00f8sningen, sker der en indfangning af den udg\u00e5ende anmodning og behandling af envoy'en, som allerede beslutter, hvilken endpoint anmodningen skal sendes til (eller ikke sendes, i tilf\u00e6lde af adgangspolitikker eller circuit breaker algoritmen aktiveres).<\/p>\n

    Nu hvor vi har forst\u00e5et Pilot, skal vi nu forst\u00e5, hvordan Mixer fungerer, og hvorfor det er n\u00f8dvendigt. Den officielle dokumentation for det kan l\u00e6ses her<\/a><\/noindex>.<\/p>\n

    Mixer i sin nuv\u00e6rende form best\u00e5r af to komponenter: istio-telemetry, istio-policy (indtil version 0.8 var det \u00e9n komponent, istio-mixer). Begge repr\u00e6senterer mixer, hvor hver is\u00e6r har sin egen opgave. Istio telemetry modtager via GRPC fra sidecar-containere Report information om, hvem der g\u00e5r hvor hen, og med hvilke parametre. Istio-policy modtager Check-foresp\u00f8rgsler for at kontrollere opfyldelsen af politikregler. Policy-tjek udf\u00f8res selvf\u00f8lgelig ikke p\u00e5 hver foresp\u00f8rgsel, men caches p\u00e5 klienten (i sidecar) i en bestemt tidsperiode. Report-tjek sendes i batch-foresp\u00f8rgsler. Hvordan man konfigurerer og hvilke specifikke parametre der skal sendes, ser vi lidt senere. <\/p>\n

    Mixer er designet som en h\u00f8jtilg\u00e6ngelig komponent, der sikrer en uafbrudt drift i indsamlingen og behandlingen af telemetry-data. Systemet ender derfor som en flerlagspuffer. Oprindeligt buffes data p\u00e5 siden af sidecar-containere, derefter p\u00e5 siden af mixer, og sendes s\u00e5 til de s\u00e5kaldte mixer-backend'er. S\u00e5 hvis en af systemets komponenter fejler, vokser pufferen, og efter systemets genopretning t\u00f8mmes den. Mixer-backend'er repr\u00e6senterer slutpunkterne for sending af telemetry-data: statsd, newrelic osv. Man kan skrive sin egen backend, det er relativt enkelt, og vi ser p\u00e5, hvordan man g\u00f8r dette.<\/p>\n

    \"Hvordan
    \n
    \nSammenfattende er arbejdsordenen med istio-telemetry som f\u00f8lger.<\/p>\n

      \n
    1. Service 1 sender en foresp\u00f8rgsel til service 2.<\/li>\n
    2. Ved udgang fra service 1 pakkes foresp\u00f8rgslen ind i dens egen sidecar.<\/li>\n
    3. Sidecar envoy holder \u00f8je med, hvordan foresp\u00f8rgslen forl\u00f8ber til service 2 og forbereder de n\u00f8dvendige oplysninger.<\/li>\n
    4. Derefter sender den disse oplysninger til istio-telemetry via en Report-foresp\u00f8rgsel.<\/li>\n
    5. Istio-telemetry bestemmer, om denne Report skal sendes til backend'er, til hvilke specifikt, og hvilke data der skal sendes.<\/li>\n
    6. Istio-telemetry sender Report-data til backend, hvis det er n\u00f8dvendigt.<\/li>\n<\/ol>\n

      \nLad os nu se, hvordan man implementerer et system i Istio, der kun best\u00e5r af de grundl\u00e6ggende komponenter (Pilot og sidecar envoy).<\/p>\n

      F\u00f8rst ser vi p\u00e5 den grundl\u00e6ggende konfiguration (mesh), som Pilot l\u00e6ser:<\/p>\n

      apiVersion: v1\nkind: ConfigMap\nmetadata:\n  name: istio\n  namespace: istio-system\n  labels:\n    app: istio\n    service: istio\ndata:\n  mesh: |-\n\n    # Vi aktiverer stadig ikke sendning af tracing information (pilot konfigurerer envoy'erne s\u00e5ledes, at der ikke vil blive sendt indhold)\n    enableTracing: false\n\n    # Vi angiver stadig ikke mixer endpoint\u2019ene, s\u00e5 sidecar containere ikke sender information dertil\n    #mixerCheckServer: istio-policy.istio-system:15004\n    #mixerReportServer: istio-telemetry.istio-system:15004\n\n    # Vi angiver den tidsperiode, hvor envoy vil sp\u00f8rge Pilot igen (dette er for den gamle version af envoy proxy)\n    rdsRefreshDelay: 5s\n\n    # default konfiguration for envoy sidecar\n    defaultConfig:\n      # ligesom rdsRefreshDelay\n      discoveryRefreshDelay: 5s\n\n      # vi efterlader som standard (stien til konfigurationen og bin\u00e6ren for envoy)\n      configPath: \"\/etc\/istio\/proxy\"\n      binaryPath: \"\/usr\/local\/bin\/envoy\"\n\n      # standardnavn for den k\u00f8rende sidecar container (bruges f.eks. i servicenavne ved sending af tracing span'ene)\n      serviceCluster: istio-proxy\n\n      # tiden, som envoy venter, f\u00f8r den tvangsm\u00e6ssigt afslutter alle etablerede forbindelser\n      drainDuration: 45s\n      parentShutdownDuration: 1m0s\n\n      # som standard bruges REDIRECT regler iptables. Kan \u00e6ndres til TPROXY.\n      #interceptionMode: REDIRECT\n\n      # Porten, hvor adminpanelet for hver sidecar container (envoy) vil blive k\u00f8rt\n      proxyAdminPort: 15000\n\n      # adressen, hvor tracing vil blive sendt via zipkin protokollen (til at begynde med har vi sl\u00e5et selve afsendelsen fra, s\u00e5 dette felt vil ikke blive brugt nu)\n      zipkinAddress: tracing-collector.tracing:9411\n\n      # statsd adresse til at sende metrics fra envoy containere (slukket)\n      # statsdUdpAddress: aggregator:8126\n\n      # slukker for underst\u00f8ttelse af Mutual TLS optionen\n      controlPlaneAuthPolicy: NONE\n\n      # adressen, hvor istio-pilot vil lytte for at informere om service discovery til alle sidecar containere\n      discoveryAddress: istio-pilot.istio-system:15007\n<\/code><\/pre>\n
      \nVi placerer alle hovedkomponenter til kontrolplanen i namespace istio-system i Kubernetes.<\/p>\n
      Minimum kr\u00e6ver vi kun at implementere Pilot. Til dette vil vi bruge denne konfiguration.<\/a><\/noindex><\/p>\n
      Og vi konfigurerer manuelt injecting sidecar containeren.<\/p>\n
      Init container:<\/p>\n
      initContainers:\n - name: istio-init\n   args:\n   - -p\n   - \"15001\"\n   - -u\n   - \"1337\"\n   - -m\n   - REDIRECT\n   - -i\n   - '*'\n   - -b\n   - '*'\n   - -d\n   - \"\"\n   image: istio\/proxy_init:1.0.0\n   imagePullPolicy: IfNotPresent\n   resources:\n     limits:\n       memory: 128Mi\n   securityContext:\n     capabilities:\n       add:\n       - NET_ADMIN\n<\/code><\/pre>\n
      \nOg sidecar:<\/p>\n
             name: istio-proxy\n       args:\n         - \"bash\"\n         - \"-c\"\n         - |\n           exec \/usr\/local\/bin\/pilot-agent proxy sidecar \n           --configPath \n           \/etc\/istio\/proxy \n           --binaryPath \n           \/usr\/local\/bin\/envoy \n           --serviceCluster \n           service-name \n           --drainDuration \n           45s \n           --parentShutdownDuration \n           1m0s \n           --discoveryAddress \n           istio-pilot.istio-system:15007 \n           --discoveryRefreshDelay \n           1s \n           --connectTimeout \n           10s \n           --proxyAdminPort \n           \"15000\" \n           --controlPlaneAuthPolicy \n           NONE\n         env:\n         - name: POD_NAME\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.name\n         - name: POD_NAMESPACE\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.namespace\n         - name: INSTANCE_IP\n           valueFrom:\n             fieldRef:\n               fieldPath: status.podIP\n         - name: ISTIO_META_POD_NAME\n           valueFrom:\n             fieldRef:\n               fieldPath: metadata.name\n         - name: ISTIO_META_INTERCEPTION_MODE\n           value: REDIRECT\n         image: istio\/proxyv2:1.0.0\n         imagePullPolicy: IfNotPresent\n         resources:\n           requests:\n             cpu: 100m\n             memory: 128Mi\n           limits:\n             memory: 2048Mi\n         securityContext:\n           privileged: false\n           readOnlyRootFilesystem: true\n           runAsUser: 1337\n         volumeMounts:\n         - mountPath: \/etc\/istio\/proxy\n           name: istio-envoy\n<\/code><\/pre>\n
      \nFor everything to start successfully, a ServiceAccount, ClusterRole, ClusterRoleBinding, and CRD for Pilot need to be created, the descriptions of which can be found her<\/a><\/noindex>. <\/p>\n
      As a result, the service into which we inject the sidecar with envoy should successfully start, receive all discovery from the pilot, and handle requests.<\/p>\n
      It is important to understand that all components of the control plane are stateless applications and can be easily scaled horizontally. All data is stored in etcd as custom Kubernetes resource descriptions.<\/p>\n
      Istio also has the option (currently experimental) to run outside the cluster and the ability to view and share service discovery between multiple Kubernetes clusters. More details can be found her<\/a><\/noindex>.<\/p>\n
      When performing a multi-cluster installation, the following limitations should be considered:<\/p>\n
        \n
      1. Pod CIDR and Service CIDR must be unique across all clusters and must not overlap.<\/li>\n
      2. All Pod CIDRs must be accessible from any Pod CIDRs between clusters.<\/li>\n
      3. All Kubernetes API servers must be accessible to one another.<\/li>\n<\/ol>\n
        \nThese are initial insights that will help you get started with Istio. However, there are still many pitfalls. For example, the peculiarities of routing external traffic (out of the cluster), approaches to debugging sidecars, profiling, configuring the mixer and writing a custom mixer backend, setting up tracing mechanisms, and how they work with envoy.
        \nVi vil d\u00e6kke alt dette i de kommende artikler. Stil dine sp\u00f8rgsm\u00e5l, s\u00e5 vil jeg g\u00f8re mit bedste for at besvare dem.
        \n
        Kilde:         habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
        \u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 Istio? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e. \u041c\u044b \u043f\u0435\u0440\u0435\u0445\u0432\u0430\u0442\u044b\u0432\u0430\u0435\u043c \u0432\u0435\u0441\u044c \u0438\u043b\u0438 \u0447\u0430\u0441\u0442\u044c \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 \u0438 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u043c \u043e\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0439 \u043d\u0430\u0431\u043e\u0440 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u0439 \u0441 \u043d\u0438\u043c. \u041a\u0430\u043a\u043e\u0439 \u0438\u043c\u0435\u043d\u043d\u043e? \u041d\u0430\u043f\u0440\u0438\u043c\u0435\u0440, \u0434\u0435\u043b\u0430\u0435\u043c \u0443\u043c\u043d\u044b\u0439 \u0440\u043e\u0443\u0442\u0438\u043d\u0433, \u0438\u043b\u0438 \u0440\u0435\u0430\u043b\u0438\u0437\u0443\u0435\u043c \u043f\u043e\u0434\u0445\u043e\u0434 circuit breaker, \u043c\u043e\u0436\u0435\u043c \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u043e\u0432\u044b\u0432\u0430\u0442\u044c \u00abcanary deployment\u00bb, \u0447\u0430\u0441\u0442\u0438\u0447\u043d\u043e \u043f\u0435\u0440\u0435\u043a\u043b\u044e\u0447\u0430\u044f \u0442\u0440\u0430\u0444\u0438\u043a \u043d\u0430 \u043d\u043e\u0432\u0443\u044e \u0432\u0435\u0440\u0441\u0438\u044e \u0441\u0435\u0440\u0432\u0438\u0441\u0430, \u0430 \u043c\u043e\u0436\u0435\u043c \u043e\u0433\u0440\u0430\u043d\u0438\u0447\u0438\u0432\u0430\u0442\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24545,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32766","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47S\u00e5dan starter du Istio ved hj\u00e6lp af Kubernetes i produktion. Del 1 | ProHoster","description":"Hvad er Istio? Det er en s\u00e5kaldt service mesh, en teknologi, der tilf\u00f8jer et abstraheringslag over netv\u00e6rket.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u0437\u0430\u043f\u0443\u0441\u0442\u0438\u0442\u044c Istio, \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u044f Kubernetes \u0432 production. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u0427\u0442\u043e \u0442\u0430\u043a\u043e\u0435 Istio? \u042d\u0442\u043e \u0442\u0430\u043a \u043d\u0430\u0437\u044b\u0432\u0430\u0435\u043c\u044b\u0439 Service mesh, \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f \u0434\u043e\u0431\u0430\u0432\u043b\u044f\u0435\u0442 \u0443\u0440\u043e\u0432\u0435\u043d\u044c \u0430\u0431\u0441\u0442\u0440\u0430\u043a\u0446\u0438\u0438 \u043d\u0430\u0434 \u0441\u0435\u0442\u044c\u044e.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/kak-zapustit-istio-ispolzuya-kubernetes-v-production-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:48+00:00","article:modified_time":"2019-10-31T18:48:48+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32766","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 12:27:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:53:24","updated":"2026-01-21 12:27:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32766","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=32766"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/32766\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/24545"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=32766"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=32766"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=32766"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}