Jaka jest różnica między zasobnikiem a wdrożeniem?

Tworzyłem strąki, type:deploymentale widzę, że niektóre zastosowania dokumentacji type:pod, a dokładniej dokumentacji dla strąków z wieloma kontenerami :

apiVersion: v1
kind: Pod
metadata:
  name: ""
  labels:
    name: ""
  namespace: ""
  annotations: []
  generateName: ""
spec:
  ? "// See 'The spec schema' for details."
  : ~

Ale aby utworzyć strąki, mogę po prostu użyć typu wdrożenia :

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: ""
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: ""
    spec:
      containers:
        etc

Zauważyłem, że dokumentacja kapsułki mówi:

Komendy tworzenia można użyć do bezpośredniego utworzenia zasobnika lub utworzenia zasobnika lub zasobników poprzez wdrożenie. Zdecydowanie zaleca się użycie Wdrażania do tworzenia swoich strąków. Wyszukuje uszkodzone kapsułki i uruchomi nowe kapsułki, aby utrzymać określoną liczbę. Jeśli nie chcesz, aby wdrożenie monitorowało Twój zasobnik (np. Twój zasobnik zapisuje nietrwałe dane, które nie przetrwają restartu, lub zasobnik ma być bardzo krótkotrwały), możesz utworzyć zasobnik bezpośrednio za pomocą polecenie tworzenia.

Uwaga: Zalecamy korzystanie z wdrożenia do tworzenia strąków. Poniższych instrukcji należy używać tylko wtedy, gdy nie chcesz tworzyć obrazu stanowiska.

Ale to rodzi pytanie o to, do czego kind:podsłuży? Czy potrafisz jakoś odwołać się do strąków we wdrożeniu? Nie widziałem sposobu. Wygląda na to, że to, co otrzymujesz z zasobników, to dodatkowe metadane, ale żadna z opcji wdrażania, takich jak replicazasada restartu. Co dobrego ma kapsuła, która nie przechowuje danych, przetrwa restart? Myślę, że byłbym w stanie stworzyć pojemnik na wiele kontenerów z wdrożeniem.

Zarówno Pod, jak i Wdrożenie są pełnoprawnymi obiektami w API Kubernetes. Wdrożenie zarządza tworzeniem kapsuł za pomocą ReplicaSets. Sprowadza się to do tego, że wdrożenie utworzy kapsuły ze specyfikacją wziętą z szablonu. Jest raczej mało prawdopodobne, że kiedykolwiek będziesz musiał tworzyć strąki bezpośrednio na potrzeby produkcji.

Odpowiedź Radka jest bardzo dobra, ale chciałbym rzucić okiem z mojego doświadczenia, prawie nigdy nie użyjesz przedmiotu z taką kapsułą , ponieważ w praktyce nie ma to żadnego sensu.

Bo trzeba wdrażania przedmiot - lub innych obiektów API Kubernetes niczym kontrolera replikacji lub replicaset - który musi utrzymać repliki (w strąkach) (żywy, który jest rodzajem punktu używając kubernetes).

W praktyce użyjesz do typowego zastosowania:

1. Obiekt wdrażania (w którym określisz kontener / kontenery aplikacji), który będzie hostował kontener aplikacji z pewnymi innymi specyfikacjami.

2. Obiekt usługi (który jest jak obiekt grupujący i nadaje mu tak zwany wirtualny adres IP (klaster IP) dla tych, podsktóre mają określoną etykietę - i podssą to zasadniczo kontenery aplikacji, które zostały wdrożone przy użyciu poprzedniego obiektu wdrażania ).

Musisz mieć obiekt usługi, ponieważ obiekt podswdrożenia może zostać zabity, skalowany w górę i w dół, a nie możesz polegać na ich adresach IP, ponieważ nie będą trwałe.

Potrzebujesz więc obiektu takiego jak usługa , który zapewni podsim stabilny adres IP.

Chciałem tylko dać ci kontekst pods, abyś wiedział, jak rzeczy działają razem.

Mam nadzieję, że to wyjaśni ci kilka rzeczy, nie tak dawno byłem w twoich butach :)

Kubernetes ma trzy typy obiektów, o których powinieneś wiedzieć:

• Strąki - uruchamia jeden lub więcej ściśle powiązanych pojemników
• Usługi - konfiguruje sieć w klastrze Kubernetes
• Wdrażanie - utrzymuje zestaw identycznych zasobników, zapewniając, że mają one prawidłową konfigurację i że istnieje ich odpowiednia liczba.

Strąki:

• Działa pojedynczy zestaw kontenerów
• Dobry do jednorazowych celów programistycznych
• Rzadko stosowany bezpośrednio w produkcji

Rozlokowanie:

• Prowadzi zestaw identycznych strąków
• Monitoruje stan każdego zasobnika, aktualizując w razie potrzeby
• Dobry dla programistów
• Dobry do produkcji

I zgodziłbym się z innymi odpowiedziami, zapomniałem o kapsułach i po prostu użyłem wdrożenia. Czemu? Spójrz na drugi punkt, monitoruje stan każdej kapsułki, aktualizując w razie potrzeby.

Zamiast walczyć z komunikatami o błędach, takimi jak ten:

Zabronione: aktualizacje kapsuły nie mogą zmieniać pól innych niż spec.containers[*].image

Po prostu dokonaj refaktoryzacji lub całkowicie odtwórz swoją kapsułę w instalacji, która tworzy kapsułę, aby zrobić to, czego potrzebujesz. Dzięki wdrożeniu możesz zmienić dowolną konfigurację i nie musisz się martwić wyświetleniem tego komunikatu o błędzie.

Pod jest instancją kontenera.

To jest wynik replicas: 3

Pomyśl, że deploymentmożna mieć wiele uruchomionych instancji (repliki).

//deployment.yaml
apiVersion: apps/v1beta2
kind: Deployment
metadata:
  name: tomcat-deployment222
spec:
  selector:
    matchLabels:
      app: tomcat
  replicas: 3
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:9.0
        ports:
        - containerPort: 8080

Pod jest kolekcją pojemników i podstawowym przedmiotem Kuberntes. Wszystkie pojemniki z kapsułą leżą w tym samym węźle.

• Nie nadaje się do produkcji
• Brak ciągłych aktualizacji

Wdrożenie jest rodzajem kontrolera w Kubernetes.

Controllers use a Pod Template that you provide to create the Pods for which it is responsible.

Wdrożenie tworzy ReplicaSet, który z kolei upewnia się, że CurrentReplicas jest zawsze taki sam, jak pożądaneReplicas.

Zalety :

• Możesz wdrażać i wycofywać zmiany za pomocą wdrożenia
• Monitoruje stan każdego zasobnika
• Najlepiej nadaje się do produkcji
• Obsługuje ciągłe aktualizacje

Chcę dodać kilka informacji z książki Kubernetes In Action , abyś mógł zobaczyć wszystkie zdjęcia i powiązania między zasobami Kubernetes, takimi jak Pod, Deployment and ReplicationController (ReplicaSet)

Strąki

są podstawową jednostką do wdrożenia w Kubernetes. Ale w rzeczywistych przypadkach użycia chcesz, aby Twoje wdrożenia działały automatycznie i działały bez problemów, bez ręcznej interwencji. W tym celu zaleca się podejście jest użycie Deployment , który pod maską utworzyć ReplicaSet .

ReplicaSet , jak sama nazwa wskazuje, jest to zestaw replik (strąków) utrzymywane z ich Przejrzano historii.

(ReplicaSet rozszerza starszy obiekt o nazwie ReplicationController - który jest dokładnie taki sam, ale bez historii wersji).

ReplicaSet stale monitoruje listę działających kapsuł i upewnia się, że bieżąca liczba kapsuł zgodnych z określoną specyfikacją zawsze odpowiada żądanej liczbie.

Removing a pod from the scope of the ReplicationController comes in handy
when you want to perform actions on a specific pod. For example, you might 
have a bug that causes your pod to start behaving badly after a specific amount 
of time or a specific event.

Deployment

jest zasobem wyższego poziomu przeznaczonym do wdrażania aplikacji i deklaratywnej ich aktualizacji.

Podczas tworzenia Deployment , A ReplicaSet zasób jest utworzony pod spodem (w końcu kilka z nich). ReplicaSets również replikuje i zarządza zasobnikami. Podczas korzystania z wdrożenia rzeczywiste zasobniki są tworzone i zarządzane przez ReplicaSets wdrożenia , a nie bezpośrednio przez wdrożenie

Zastanówmy się, co się stało. Zmieniając szablon zasobnika w zasobie wdrażania, zaktualizowałeś aplikację do nowszej wersji - zmieniając jedno pole!

Na koniec przywróć wdrożenie do poprzedniej lub dowolnej wcześniejszej wersji, tak łatwe dzięki zasobom do wdrażania.

Te obrazy również pochodzą z książki Kubernetes In Action .

Staraj się unikać kapsuł i wdrożyć zamiast nich wdrożenia do zarządzania kontenerami, ponieważ obiekty rodzaju kapsuły nie zostaną ponownie zaplanowane (lub samoleczą się) w przypadku awarii węzła lub zakończenia kapsuły.

Wdrożenie jest ogólnie preferowane, ponieważ definiuje zestaw repliki, aby zapewnić, że żądana liczba kapsuł jest zawsze dostępna i określa strategię zastępowania kapsuł, na przykład RollingUpdate.

W kubernetes Kapsuły to najmniejsze jednostki do rozmieszczenia. Za każdym razem, gdy tworzymy obiekt kubernetes, taki jak Wdrożenia, zestawy replik, zestawy stanowe, daemonsets, tworzy pod.

Jak wspomniano powyżej, wdrożenia tworzą strąki w oparciu o pożądany stan wymieniony w obiekcie wdrażania. Na przykład chcesz 5 replik aplikacji wymienionych replicas: 5w manifeście wdrożenia. Teraz kontroler wdrażania jest odpowiedzialny za utworzenie 5 identycznych replik (nie mniej, nie więcej) danej aplikacji ze wszystkimi metadanymi, takimi jak polityka RBAC, polityka sieci, etykiety, adnotacje, kontrola kondycji, przydziały zasobów, skażenie / tolerancje i inne oraz powiązanie z każdym zasobnikiem to tworzy.

W niektórych przypadkach chcesz utworzyć pod, na przykład jeśli uruchamiasz testowy wózek boczny, w którym nie musisz uruchamiać aplikacji na zawsze, nie potrzebujesz wielu replik i uruchamiasz aplikację, gdy chcesz wykonać w tym celu futerał na kapsułkę jest odpowiedni. Na przykład helm test, która jest definicją zasobnika, która określa kontener z danym poleceniem do uruchomienia.