Jak dokonywane są zmiany w Kubernetes deklaratywnie?¶
Zmiany deklaratywne w Kubernetes możemy dokonywać poleceniem:
Dzięki takiemu podejściu mamy pewność, że zmiany wprowadzone są: - ostateczne - idempotentne (niezależnie ile razy wykonamy tą samą operację, wynik będzie identyczny) - wynik zawsze jest spójny, rozwiązywane są konflikty
Apply używa 3-way merge → bezpieczne aktualizacje¶
kubectl apply porównuje:
1. stan w klastrze (live object)
2. Twój plik (desired state)
3. stan ostatnio zastosowany (last applied)
W pliku last applied mamy ostatnie dokonane zmiany.
Last applied pozwala Kubernetesowi wykrywać, co użytkownik zmienił lub usunął od ostatniego apply, ale nie jest to mechanizm do cofania zmian sam w sobie.
Zmiany są zapisywane w adnotacjach, w selektorze:
metadata.annotations.kubectl.kubernetes.io/last-applied-configuration.
Dzięki apply możliwe jest także podejście GitOps, wybieramy dosłownie każdy z możliwie zapisanych manifestów, zmiany są dokonywane dynamicznie.
Apply umożliwia GitOps, bo klaster jest zawsze doprowadzany do stanu opisanego w plikach, a nie modyfikowany ręcznie jak przy edit
Gdy zrobimy edit możemy nadpisać taką zmianę i nie będzie możliwości odczytać tego co zostało zmienione w klastrze.
kubectl edit modyfikuje live object bez aktualizacji last applied configuration. apply nie wie, które zmiany zostały wykonane ręcznie i następny apply może nadpisać te zmiany lub je wymazać, jeśli nie są w YAML.
Podsumowująć Last applied ma wpływ tylko na to co się wprowadziło w manifeście (np. jakieś pole). Gdy ktoś zmieni w edit pole, które jest w manifeście, następnie zrobie apply, wtedy Kubernetes nadpisze zmiany.
Gdy nie ma tego w Last applied, a ja zrobie edit (np. pole labels) wtedy kolejne kubectl apply -f ... nie nadpisze/usunie utworzonego Labela.