{"id":35955,"date":"2019-10-31T22:08:26","date_gmt":"2019-10-31T19:08:26","guid":{"rendered":"https:\/\/prohoster.info\/blog\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm\/"},"modified":"2019-10-31T22:08:26","modified_gmt":"2019-10-31T19:08:26","slug":"razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","title":{"rendered":"Implementatie van applicaties op meerdere Kubernetes-clusters met Helm","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<\/p>\n<p><\/p>\n<h2 id=\"kak-dailymotion-ispolzuet-kubernetes-razvertyvanie-prilozheniy\">Hoe Dailymotion Kubernetes gebruikt: applicatiedeployments<\/h2>\n<p><\/p>\n<p>Bij Dailymotion zijn we drie jaar geleden begonnen met het gebruik van Kubernetes in productie. Maar het is geen gemakkelijke taak om applicaties op meerdere clusters te deployen, dus hebben we de afgelopen jaren geprobeerd onze tools en workflows te verbeteren.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3 id=\"s-chego-nachalos\">Waar het mee begon<\/h3>\n<p><\/p>\n<p>Hier vertellen we hoe we onze applicaties op meerdere Kubernetes-clusters over de hele wereld implementeren.<\/p>\n<p><\/p>\n<p>Om meerdere Kubernetes-objecten in \u00e9\u00e9n keer te implementeren, gebruiken we <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/\">Helm<\/a><\/noindex>, en al onze charts worden in \u00e9\u00e9n git-repository opgeslagen. Om een volledige applicatiestack van meerdere services te implementeren, gebruiken we een zogenaamde aggregator chart. Dit is in wezen een chart die afhankelijkheden declareert en het mogelijk maakt om de API en zijn services met \u00e9\u00e9n commando te initialiseren.<\/p>\n<p><\/p>\n<p>Daarnaast hebben we een kleine Python-script bovenop Helm geschreven om controles uit te voeren, charts te cre\u00ebren, geheimen toe te voegen en applicaties te implementeren. Al deze taken worden uitgevoerd op een centraal CI-platform met behulp van een Docker-image.<\/p>\n<p><\/p>\n<p>Laten we naar de kern gaan.<\/p>\n<p><\/p>\n<blockquote><p>Opmerking. Wanneer je dit leest, is de eerste releasecandidate van Helm 3 al aangekondigd. De belangrijkste versie bevat een hele reeks verbeteringen die zijn ontworpen om enkele problemen aan te pakken waarmee we in het verleden te maken hadden.<\/p><\/blockquote>\n<p><\/p>\n<h3 id=\"rabochiy-process-razrabotki-chartov\">Workflow voor het ontwikkelen van charts<\/h3>\n<p><\/p>\n<p>Voor applicaties gebruiken we branching, en we hebben besloten dezelfde aanpak op charts toe te passen.<\/p>\n<p><\/p>\n<ul>\n<li>De tak <strong>, maar volgt geen wijzigingen), gebruikmakend van een andere configuratie.<\/strong> wordt gebruikt voor het cre\u00ebren van charts die op ontwikkelingsclusters worden getest.<\/li>\n<li>Wanneer een pull request wordt ingediend in <strong>master<\/strong>, worden ze in de staging getest.<\/li>\n<li>Ten slotte maken we een pull request om de wijzigingen naar de tak te brengen <strong>prod<\/strong> en deze toe te passen in productie.<\/li>\n<\/ul>\n<p><\/p>\n<p>Elke omgeving heeft zijn eigen priv\u00e9repository waarin onze charts worden opgeslagen, en we gebruiken <noindex><a rel=\"nofollow\" href=\"https:\/\/chartmuseum.com\/\">Chartmuseum<\/a><\/noindex> met zeer nuttige API's. Dit zorgt ervoor dat we strikte isolatie tussen omgevingen garanderen en charts onder re\u00eble omstandigheden testen voordat we ze in productie gebruiken.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/rz\/vt\/uk\/rzvtuk6q7b_rkeaxnyujzhmfjog.png\"><\/a><\/noindex><\/p>\n<p><\/p>\n<p><em>Chartrepositories in verschillende omgevingen<\/em><\/p>\n<p><\/p>\n<p>Het is vermeldenswaard dat wanneer ontwikkelaars een dev-tak indienen, hun chartversie automatisch naar dev Chartmuseum wordt gestuurd. Zo gebruiken alle ontwikkelaars \u00e9\u00e9n dev-repository, en is het belangrijk om de chartversie nauwkeurig op te geven om te voorkomen dat per ongeluk iemand anders' wijzigingen worden gebruikt.<\/p>\n<p><\/p>\n<p>Bovendien controleert ons kleine Python-script Kubernetes-objecten op basis van de Kubernetes OpenAPI-specificaties met behulp van <noindex><a rel=\"nofollow\" href=\"https:\/\/kubeval.instrumenta.dev\/\">Kubeval<\/a><\/noindex>, voordat we ze in Chartmuseum publiceren.<\/p>\n<p><\/p>\n<h3 id=\"obschee-opisanie-rabochego-processa-razrabotki-charta\">Algemene beschrijving van de chart-ontwikkeling workflow<\/h3>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/yd\/cw\/qw\/ydcwqw-vqfitu5bj8ky4nh7xxea.png\"><\/a><\/noindex><\/p>\n<p><\/p>\n<ol>\n<li>Configuratie van pipeline-taken volgens de specificatie <noindex><a rel=\"nofollow\" href=\"https:\/\/gazr.io\/\">gazr.io<\/a><\/noindex> voor kwaliteitscontrole (lint, unit-test).<\/li>\n<li>Verzending van de docker-image met Python-tools die onze applicaties uitrollen.<\/li>\n<li>Configuratie van de omgeving op basis van de branchnaam.<\/li>\n<li>Controleren van Kubernetes yaml-bestanden met Kubeval.<\/li>\n<li>Automatische versie-increment van de chart en zijn oudercharts (charts die afhankelijk zijn van de wijzigende chart).<\/li>\n<li>Verzending van de chart naar Chartmuseum, die overeenkomt met zijn omgeving<\/li>\n<\/ol>\n<p><\/p>\n<h2 id=\"upravlenie-razlichiyami-v-klasterah\">Beheer van verschillen in clusters<\/h2>\n<p><\/p>\n<h3 id=\"federaciya-klasterov\">Federatie van clusters<\/h3>\n<p><\/p>\n<p>Er was een tijd dat we gebruikten <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/cluster-administration\/federation\/\">de federatie van Kubernetes-clusters<\/a><\/noindex>, waar we Kubernetes-objecten vanuit \u00e9\u00e9n API-eindpunt konden maken. Maar er waren problemen. Bijvoorbeeld, sommige Kubernetes-objecten konden niet worden aangemaakt via het federatie-eindpunt, waardoor het moeilijk was om geaggregeerde objecten en andere objecten voor afzonderlijke clusters te beheren.<\/p>\n<p><\/p>\n<p>Om het probleem op te lossen, zijn we onafhankelijk gaan beheren van clusters, wat het proces aanzienlijk vereenvoudigde (we gebruikten de eerste versie van de federatie; in de tweede kon er iets gewijzigd zijn).<\/p>\n<p><\/p>\n<h3 id=\"georaspredelennaya-platforma\">Geodistribueerd platform<\/h3>\n<p><\/p>\n<p>Momenteel is ons platform verspreid over 6 regio's\u20143 lokaal en 3 in de cloud.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/jq\/c1\/mr\/jqc1mru36g5byams4wddzducauw.png\"><\/a><\/noindex><br \/>\n<em>Distributed deployment<\/em><\/p>\n<p><\/p>\n<h3 id=\"globalnye-znacheniya-helm\">Globale Helm-waarden<\/h3>\n<p><\/p>\n<p>4 globale Helm-waarden maken het mogelijk om verschillen tussen clusters vast te stellen. Voor al onze charts zijn er minimale standaardwaarden.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">global:\n  cloud: True\n  env: staging\n  region: us-central1\n  clusterName: staging-us-central1<\/code><\/pre>\n<p><\/p>\n<p><em>Globale waarden<\/em><\/p>\n<p><\/p>\n<p>Deze waarden helpen om context te bepalen voor onze applicaties en worden gebruikt voor verschillende taken: monitoring, tracing, logging, externe aanroepen, schaling, enzovoorts.<\/p>\n<p><\/p>\n<ul>\n<li>\"cloud\": we hebben een hybride Kubernetes-platform. Bijvoorbeeld, onze API wordt uitgerold in GCP-zones en in onze datacenters.<\/li>\n<li>\"env\": sommige waarden kunnen vari\u00ebren voor niet-werkende omgevingen. Bijvoorbeeld, resource-definities en auto-scalingconfiguraties.<\/li>\n<li>\"region\": deze informatie helpt het locatie van het cluster te bepalen en kan worden gebruikt om de dichtstbijzijnde eindpunten voor externe services te identificeren.<\/li>\n<li>\"clusterName\": als en wanneer we een waarde voor een afzonderlijk cluster willen defini\u00ebren.<\/li>\n<\/ul>\n<p><\/p>\n<p>Hier is een concreet voorbeeld:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">{{\n\/* Retourneert de replicaten van de Horizontal Pod Autoscaler voor GraphQL*\/}}\n{{- define \"graphql.hpaReplicas\" -}}\n{{- if eq .Values.global.env \"prod\" }}\n{{- if eq .Values.global.region \"europe-west1\" }}\nminReplicas: 40\n{{- else }}\nminReplicas: 150\n{{- end }}\nmaxReplicas: 1400\n{{- else }}\nminReplicas: 4\nmaxReplicas: 20\n{{- end }}\n{{- end -}}<\/code><\/pre>\n<p><\/p>\n<p><em>Voorbeeld van een Helm-sjabloon<\/em><\/p>\n<p><\/p>\n<p>Deze logica is gedefinieerd in een hulpsjabloon om Kubernetes YAML niet te vervuilen.<\/p>\n<p><\/p>\n<h3 id=\"obyavlenie-prilozheniya\">Applicatieverklaring<\/h3>\n<p><\/p>\n<p>Onze implementatietools zijn gebaseerd op verschillende YAML-bestanden. Hieronder staat een voorbeeld van hoe we een service en zijn schaalstructuur (aantal replicaten) in de cluster verklaren.<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">releases:\n  - foo.world\n\nfoo.world:                # Naam van de release\n  services:               # Lijst van dailymotion's apps\/projecten\n    foobar:\n      chart_name: foo-foobar\n      repo: git@github.com:dailymotion\/foobar\n      contexts:\n        prod-europe-west1:\n          deployments:\n            - name: foo-bar-baz\n              replicas: 18\n            - name: another-deployment\n              replicas: 3<\/code><\/pre>\n<p><\/p>\n<p><em>Servicedefinitie<\/em><\/p>\n<p><\/p>\n<p>Dit is een schema van alle stappen die onze implementatieworkflow defini\u00ebren. De laatste stap implementeert de applicatie gelijktijdig op meerdere werkklusters.<\/p>\n<p><\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/habrastorage.org\/webt\/iu\/qh\/xk\/iuqhxki4nfqoi0mus258j0feylu.png\"><\/a><\/noindex><br \/>\n<em>Implementatiestappen in Jenkins<\/em><\/p>\n<p><\/p>\n<h3 id=\"a-sekrety\">En de secrets?<\/h3>\n<p><\/p>\n<p>Wat betreft beveiliging volgen we alle secrets vanuit verschillende bronnen en bewaren we ze in een unieke opslag. <noindex><a rel=\"nofollow\" href=\"https:\/\/www.vaultproject.io\/\">Vault<\/a><\/noindex> in Parijs.<\/p>\n<p><\/p>\n<p>Onze implementatietools halen de waarden van secrets uit Vault en voegen, wanneer het tijd is om te implementeren, deze toe aan Helm.<\/p>\n<p><\/p>\n<p>Hiervoor hebben we een mapping gedefinieerd tussen de secrets in Vault en de secrets die onze applicaties nodig hebben:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">secrets:                                                                                                                                                                                                        \n     - secret_id: \"stack1-app1-password\"                                                                                                                                                                                  \n       contexts:                                                                                                                                                                                                   \n         - name: \"default\"                                                                                                                                                                                         \n           vaultPath: \"\\\/kv\\\/dev\\\/stack1\\\/app1\\\/test\"                                                                                                                                                               \n           vaultKey: \"password\"                                                                                                                                                                                    \n         - name: \"cluster1\"                                                                                                                                                                           \n           vaultPath: \"\\\/kv\\\/dev\\\/stack1\\\/app1\\\/test\"                                                                                                                                                               \n           vaultKey: \"password\"<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>We hebben algemene regels vastgesteld die moeten worden gevolgd bij het opslaan van geheimen in de Vault.<\/li>\n<li>Als een geheim hoort bij <strong>een bepaalde context of cluster<\/strong>, moet er een specifieke vermelding worden toegevoegd. (Hier heeft de context cluster1 een eigen waarde voor het geheim stack-app1-password).<\/li>\n<li>In andere gevallen wordt de waarde gebruikt. <strong>standaard<\/strong>.<\/li>\n<li>Voor elk item in deze lijst wordt er in de <strong>Kubernetes geheim<\/strong> een sleutel-waarde paar ingevoegd. Daarom is de sjabloon voor geheimen in onze charts erg eenvoudig.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: v1\ndata:\n{{- range $key,$value := .Values.secrets }}\n  {{ $key }}: {{ $value | b64enc | quote }}\n{{ end }}\nkind: Secret\nmetadata:\n  name: \"{{ .Chart.Name }}\"\n  labels:\n    chartVersion: \"{{ .Chart.Version }}\"\n    tillerVersion: \"{{ .Capabilities.TillerVersion.SemVer }}\"\ntype: Opaque<\/code><\/pre>\n<p><\/p>\n<h2 id=\"problemy-i-ogranicheniya\">Problemen en beperkingen<\/h2>\n<p><\/p>\n<h3 id=\"rabota-s-neskolkimi-repozitoriyami\">Werken met meerdere repositories<\/h3>\n<p><\/p>\n<p>Momenteel splitsen we de ontwikkeling van charts en applicaties. Dit betekent dat ontwikkelaars in twee git-repositories moeten werken: \u00e9\u00e9n voor de applicatie en de andere voor het defini\u00ebren van de implementatie in Kubernetes. Twee git-repositories betekent twee werkprocessen, en het is gemakkelijk voor een nieuwkomer om in de war te raken.<\/p>\n<p><\/p>\n<h3 id=\"upravlyat-obobschennymi-chartami-hlopotno\">Het beheren van generieke charts is omslachtig<\/h3>\n<p><\/p>\n<p>Zoals we al zeiden, zijn generieke charts zeer handig voor het defini\u00ebren van afhankelijkheden en het snel implementeren van meerdere applicaties. Maar we gebruiken <code>--reuse-values<\/code>, om te voorkomen dat we elke keer weer alle waarden overdragen wanneer we een applicatie implementeren die deel uitmaakt van deze generieke chart.<\/p>\n<p><\/p>\n<p>Binnen het proces van continue levering hebben we slechts twee waarden die regelmatig veranderen: het aantal exemplaren en de afbeeldingstag (versie). Andere, stabielere waarden worden handmatig gewijzigd en dat is behoorlijk ingewikkeld. Bovendien kan \u00e9\u00e9n fout in de implementatie van een algemene chart leiden tot ernstige storingen, zoals we uit eigen ervaring hebben geleerd.<\/p>\n<p><\/p>\n<h3 id=\"obnovlenie-neskolkih-faylov-konfiguracii\">Het bijwerken van meerdere configuratiebestanden<\/h3>\n<p><\/p>\n<p>Wanneer een ontwikkelaar een nieuwe applicatie toevoegt, moet hij verschillende bestanden aanpassen: de applicatieverklaring, de lijst met geheimen en het toevoegen van de applicatie aan de afhankelijkheden, als het deel uitmaakt van de algemene chart.<\/p>\n<p><\/p>\n<h3 id=\"razresheniya-jenkins-slishkom-rasshireny-v-vault\">De Jenkins-rechten zijn te uitgebreid in Vault<\/h3>\n<p><\/p>\n<p>We hebben nu \u00e9\u00e9n <noindex><a rel=\"nofollow\" href=\"https:\/\/www.vaultproject.io\/docs\/auth\/approle.html\">AppRole<\/a><\/noindex>, die alle geheimen uit Vault leest.<\/p>\n<p><\/p>\n<h3 id=\"process-otkata-ne-avtomatizirovan\">Het terugrolproces is niet geautomatiseerd<\/h3>\n<p><\/p>\n<p>Voor een terugrol moet een opdracht op meerdere clusters worden uitgevoerd, wat foutgevoelig is. We voeren deze handeling handmatig uit om ervoor te zorgen dat we de juiste versie-id opgeven.<\/p>\n<p><\/p>\n<h2 id=\"my-dvizhemsya-v-storonu-gitops\">We bewegen richting GitOps<\/h2>\n<p><\/p>\n<h3 id=\"nasha-cel\">Ons doel<\/h3>\n<p><\/p>\n<p>We willen de chart terugbrengen naar de repository van de applicatie die hij implementeert.<\/p>\n<p><\/p>\n<p>De workflow zal hetzelfde zijn als voor ontwikkeling. Bijvoorbeeld, wanneer de tak naar master wordt gepusht, wordt de implementatie automatisch gestart. Het belangrijkste verschil tussen deze aanpak en de huidige workflow is dat <strong>alles in git zal worden beheerd<\/strong> (de applicatie zelf en de manier waarop deze wordt ge\u00efmplementeerd in Kubernetes).<\/p>\n<p><\/p>\n<p>Er zijn verschillende voordelen:<\/p>\n<p><\/p>\n<ul>\n<li>Veel <strong>duidelijker<\/strong> voor de ontwikkelaar. Het is gemakkelijker om wijzigingen in de lokale chart toe te passen.<\/li>\n<li>De definitie van de service-implementatie kan worden opgegeven <strong>op dezelfde plaats als de code<\/strong> van de service.<\/li>\n<li><strong>Beheer van het verwijderen van algemene charts<\/strong>. De service zal zijn eigen Helm-release hebben. Dit stelt ons in staat om de levenscyclus van de applicatie (terugrol, upgrade) op het fijnste niveau te beheren, zodat andere services niet worden be\u00efnvloed.<\/li>\n<li><strong>Voordelen van git<\/strong> voor het beheren van charts: wijzigingen terugdraaien, auditlog, enz. Als er een wijziging in de chart moet worden teruggedraaid, kan dit met git worden gedaan. De implementatie wordt automatisch gestart.<\/li>\n<li>Men kan nadenken over het verbeteren van de ontwikkelingsworkflow met behulp van tools zoals <strong>Skaffold<\/strong>, waarmee ontwikkelaars wijzigingen kunnen testen in een omgeving die dicht bij productie ligt.<\/li>\n<\/ul>\n<p><\/p>\n<h3 id=\"dvuhetapnaya-migraciya\">Twee-fasen migratie<\/h3>\n<p><\/p>\n<p>Onze ontwikkelaars gebruiken deze workflow al 2 jaar, dus we hebben een zo soepel mogelijke migratie nodig. Daarom hebben we besloten om een tussentijdse stap in ons proces toe te voegen.<br \/>\nDe eerste stap is eenvoudig:<\/p>\n<p><\/p>\n<ul>\n<li>We behouden een vergelijkbare structuur voor het instellen van de applicatie-implementatie, maar in \u00e9\u00e9n object genaamd DailymotionRelease.<\/li>\n<\/ul>\n<p><\/p>\n<pre><code class=\"plaintext\">apiVersion: \"v1\"\nkind: \"DailymotionRelease\"\nmetadata:\n  name: \"app1.ns1\"\n  environment: \"dev\"\n  branch: \"mybranch\"\nspec:\n  slack_channel: \"#admin\"\n  chart_name: \"app1\"\n  scaling:\n    - context: \"dev-us-central1-0\"\n      replicas:\n        - name: \"hermes\"\n          count: 2\n    - context: \"dev-europe-west1-0\"\n      replicas:\n        - name: \"app1-deploy\"\n          count: 2\n  secrets:\n    - secret_id: \"app1\"\n      contexts:\n        - name: \"default\"\n          vaultPath: \"\\\/kv\\\/dev\\\/ns1\\\/app1\\\/test\"\n          vaultKey: \"password\"\n        - name: \"dev-europe-west1-0\"\n          vaultPath: \"\\\/kv\\\/dev\\\/ns1\\\/app1\\\/test\"\n          vaultKey: \"password\"<\/code><\/pre>\n<p><\/p>\n<ul>\n<li>1 release per applicatie (zonder algemene charts).<\/li>\n<li>Charts in de git-repository van de applicatie.<\/li>\n<\/ul>\n<p><\/p>\n<p>We hebben met alle ontwikkelaars gesproken, dus het migratieproces is al begonnen. De eerste stap wordt nog steeds gecontroleerd met behulp van het CI-platform. Binnenkort schrijf ik een andere post over de tweede stap: hoe we overgeschakeld zijn naar een GitOps-workflow met <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/weaveworks\/flux\">Flux<\/a><\/noindex>. Ik zal vertellen hoe we alles hebben ingesteld en met welke uitdagingen we te maken kregen (meerdere repositories, geheimen, enz.). Blijf op de hoogte.<\/p>\n<p><\/p>\n<p>Hier proberen we onze voortgang in het proces van applicatie-implementatie in de afgelopen jaren te beschrijven, wat heeft geleid tot gedachten over de GitOps-aanpak. We hebben ons doel nog niet bereikt en zullen onze resultaten blijven delen, maar we zijn er nu van overtuigd dat we het juiste hebben gedaan door alles te vereenvoudigen en dichter bij de gewoonten van ontwikkelaars te brengen.<\/p>\n<p>Bron: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/southbridge\/blog\/458934\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u0435\u043d\u0435 3 \u0433\u043e\u0434\u0430 \u043d\u0430\u0437\u0430\u0434. \u041d\u043e \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u0442\u044c \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 \u0442\u043e \u0435\u0449\u0435 \u0443\u0434\u043e\u0432\u043e\u043b\u044c\u0441\u0442\u0432\u0438\u0435, \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u0432 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u043b\u0435\u0442 \u043c\u044b \u0441\u0442\u0430\u0440\u0430\u043b\u0438\u0441\u044c \u0443\u043b\u0443\u0447\u0448\u0438\u0442\u044c \u043d\u0430\u0448\u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 \u0440\u0430\u0431\u043e\u0447\u0438\u0435 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u044b. \u0421 \u0447\u0435\u0433\u043e \u043d\u0430\u0447\u0430\u043b\u043e\u0441\u044c \u0417\u0434\u0435\u0441\u044c \u043c\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u043c\u044b \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u0435\u043c \u043d\u0430\u0448\u0438 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u044f \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 Kubernetes \u043f\u043e [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35955","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0420\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 Kubernetes \u0441 Helm | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:08:26+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:08:26+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Applicatie-implementatie op meerdere Kubernetes-clusters met Helm | ProHoster","description":"Hoe Dailymotion Kubernetes gebruikt: applicatie-implementatie We bij Dailymotion zijn begonnen met het gebruik van Kubernetes in.","canonical_url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nl_NL","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\u0420\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u043d\u0430 \u043d\u0435\u0441\u043a\u043e\u043b\u044c\u043a\u0438\u0445 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430\u0445 Kubernetes \u0441 Helm | ProHoster","og:description":"\u041a\u0430\u043a Dailymotion \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u0443\u0435\u0442 Kubernetes: \u0440\u0430\u0437\u0432\u0435\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u0435 \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0439 \u041c\u044b \u0432 Dailymotion \u043d\u0430\u0447\u0430\u043b\u0438 \u0438\u0441\u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u044c Kubernetes \u0432.","og:url":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/razvertyvanie-prilozhenij-na-neskolkih-klasterah-kubernetes-s-helm","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-31T19:08:26+00:00","article:modified_time":"2019-10-31T19:08:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35955","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-22 01:25:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:53:31","updated":"2026-01-22 01:25:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/35955","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=35955"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/35955\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=35955"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=35955"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=35955"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}