{"id":70831,"date":"2020-02-21T14:42:15","date_gmt":"2020-02-21T11:42:15","guid":{"rendered":"https:\/\/prohoster.info\/blog\/obnovlenie-kubernetes-klastera-bez-prostoya"},"modified":"2020-03-03T16:14:45","modified_gmt":"2020-03-03T13:14:45","slug":"obnovlenie-kubernetes-klastera-bez-prostoya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/administrirovanie\/obnovlenie-kubernetes-klastera-bez-prostoya","title":{"rendered":"Kubernetes-clusterupdate zonder downtime","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Kubernetes-clusterupdate<\/p>\n

Het updateproces voor uw Kubernetes-cluster<\/em><\/p>\n

<\/p>\n

Op een gegeven moment bij het gebruik van een Kubernetes-cluster ontstaat de noodzaak om de actieve nodes bij te werken. Dit kan het bijwerken van pakketten, het bijwerken van de kernel of het implementeren van nieuwe afbeeldingen van virtuele machines omvatten. In Kubernetes-terminologie wordt dit \"Vrijwillige Onderbreking\"<\/a><\/noindex>.<\/p>\n

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

Dit bericht maakt deel uit van een serie van 4 berichten:<\/p>\n

<\/p>\n

    \n
  1. Dit bericht.<\/li>\n
  2. Correct afsluiten van pods in een Kubernetes-cluster<\/li>\n
  3. Uitgestelde be\u00ebindiging van de pod tijdens het verwijderen<\/li>\n
  4. Hoe downtime in een Kubernetes-cluster te vermijden met behulp van PodDisruptionBudgets<\/li>\n<\/ol>\n

    <\/p>\n

    (opm. vert. vertalingen van de overige artikelen in de serie worden binnenkort verwacht)<\/em><\/p>\n

    <\/p>\n

    In dit artikel beschrijven we alle hulpmiddelen die Kubernetes biedt om nul downtime te bereiken voor de nodes in uw cluster.<\/p>\n

    <\/p>\n

    Probleemdefinitie<\/h2>\n

    <\/p>\n

    In eerste instantie zullen we een na\u00efeve benadering volgen, waarbij we problemen identificeren en de potenti\u00eble risico's van deze aanpak evalueren, en we kennis opbouwen om elk van de problemen waarmee we tijdens de cyclus worden geconfronteerd op te lossen. Uiteindelijk zullen we een configuratie hebben die lifecycle hooks, readiness probes en Pod disruption budgets gebruikt om onze nul downtime te bereiken. <\/p>\n

    <\/p>\n

    Om onze reis te beginnen, laten we een concreet voorbeeld nemen. Stel dat we een Kubernetes-cluster hebben met twee knooppunten, waarop een toepassing draait met twee pods, die zich achter bevinden Service<\/code>:<\/p>\n

    \n\"Kubernetes-clusterupdate<\/p>\n

    We beginnen met twee pods met Nginx en Service die draaien op onze twee nodes van het Kubernetes-cluster.<\/em><\/p>\n

    <\/p>\n

    We willen de kernelversie van de twee werkende nodes in ons cluster bijwerken. Hoe doen we dat? Een eenvoudige oplossing zou zijn om nieuwe nodes met een bijgewerkte configuratie op te starten en vervolgens de oude nodes uit te schakelen, terwijl we tegelijkertijd de nieuwe nodes in gebruik nemen. Hoewel dit zou werken, zijn er enkele problemen met deze aanpak:<\/p>\n

    <\/p>\n