Podczas instalacji systemu EZDRP zauważyłem, że w instrukcji dodawanie węzłów roboczych (worker nodes) jest określone jako opcjonalne. Z dobrych praktyk wynika, że w środowisku Kubernetes standardowo stosuje się podział na węzły główne (master nodes), które zarządzają klastrem, oraz węzły robocze, na których uruchamiane są aplikacje. Węzły robocze pełnią kluczową rolę, ponieważ to na nich działają pody z kontenerami aplikacyjnymi. Uruchamianie podów aplikacyjnych na węzłach głównych nie jest zalecaną praktyką, zwłaszcza w środowiskach produkcyjnych (kwestie skalowania). Czy nie lepsze byłoby oddzielenie ról (master, worker), które pozwala na optymalne zarządzanie zasobami? Węzły główne mogą być zoptymalizowane pod kątem wymagań komponentów kontrolnych (etcd, kube-apiserver, kube-scheduler, kube-controller-manager), a węzły robocze pod kątem obciążenia aplikacyjnego. Z czego wynika takie podejście (opcjonalne workery, praca oparta na masterach) w instrukcji instalacji EZDRP?
Z jednej strony podział na master i worker to standard w Kubernetes – wiadomo, lepsze skalowanie, stabilność i bezpieczeństwo. Mastery ogarniają zarządzanie, workery pracę aplikacji, i wszystko jest logicznie rozdzielone.
Z drugiej jednak strony – czy faktycznie zawsze warto tak sztywno trzymać się tego podziału? Może dla mniejszych środowisk, gdzie klaster nie jest mocno obciążony, uproszczenie, które widzimy w EZD RP, ma jakiś sens? A może w instrukcji chodziło o ułatwienie konfiguracji na początek, a w produkcji założono, że każdy dostosuje klaster do swoich potrzeb?
Chętnie usłyszę, co inni o tym sądzą. Może ktoś próbował wdrożyć EZDRP na większą skalę i może podzielić się, jak to działa w praktyce?
Moim zdaniem temat kluczowy i niemal zupełnie pominięty w instrukcji instalacji. Zupełnie tak, jakby instalacja systemu kończyła temat i potem sam on się utrzymywał 
Myślę, że problem na razie widzi mało kto, bo na razie mało kto utrzymuje działające dłuższy czas produkcyjnie ezdrp
Nie jestem ekspertem od kubernetesa, ale potwierdzam - wg wszelkich opinii pody aplikacyjne na masterach to nie jest zalecana praktyka (o tym też w instrukcji nie ma). W związku z tym, konfiguracja systemu na przykład z jednym tylko workerem nie ma moim zdaniem większego sensu.
Oczywiście, zgadzam się, że w przypadku systemu wystawionego testowo to nie ma aż takiego znaczenia i możemy zachować pewną elastyczność. Ale system testowy przecież ma służyć m.in. dostrzeżeniu problemów z utrzymaniem systemu produkcyjnego, jeśli środowisko testowe będzie mocno rozjechane z produkcyjnym, to każde z nich będzie żyło własnym życiem i miało specyficzne dla siebie problemy.
Weźmy na przykład problem aktualizacji maszyn workerów. Jeśli aktualizacja wymaga restartu, to generalnie powinniśmy drainować danego workera, gdzie mają podziać się pody jeśli worker jest jeden a na masterach nie tolerujemy podów aplikacji? Oczywiście, w testowym środowisku możemy machnąć restart nie martwiąc się że aplikacja nam zdechnie na czas restartu (albo i dłuższy jak coś się sypnie), ale już na produkcji nie chcemy takich przygód. Na szczęście zaletą kubernetesa jest to, że możemy dostawić kolejnego workera w miarę potrzeb, tylko że często barierą są brakujące zasoby (chyba że dysponujemy mocnymi konfiguracjami serwerowymi).