Kubernetes jak zrobić wdrożenie, aby zaktualizować obraz

Mam wdrożenie z pojedynczym pod, z moim niestandardowym obrazem platformy Docker, takim jak:

containers:
  - name: mycontainer
    image: myimage:latest

Podczas programowania chcę wypchnąć nową najnowszą wersję i zaktualizować Wdrożenie. Nie mogę znaleźć, jak to zrobić, bez wyraźnego zdefiniowania tagu / wersji i inkrementowania go dla każdej kompilacji, i zrób

kubectl set image deployment/my-deployment mycontainer=myimage:1.9.1

Możesz skonfigurować swój pod z okresem karencji (na przykład 30 sekund lub więcej, w zależności od czasu uruchamiania kontenera i rozmiaru obrazu) i ustawić "imagePullPolicy: "Always". I użyj kubectl delete pod pod_name. Zostanie utworzony nowy kontener, a najnowszy obraz zostanie automatycznie pobrany, a stary kontener zostanie zamknięty.

Przykład:

spec:
  terminationGracePeriodSeconds: 30
  containers:
  - name: my_container
    image: my_image:latest
    imagePullPolicy: "Always"

Obecnie używam Jenkinsa do automatycznych kompilacji i tagowania obrazów i wygląda to mniej więcej tak:

kubectl --user="kube-user" --server="https://kubemaster.example.com"  --token=$ACCESS_TOKEN set image deployment/my-deployment mycontainer=myimage:"$BUILD_NUMBER-$SHORT_GIT_COMMIT"

Inną sztuczką jest uruchomienie:

kubectl set image deployment/my-deployment mycontainer=myimage:latest

i wtedy:

kubectl set image deployment/my-deployment mycontainer=myimage

W rzeczywistości będzie wyzwalać aktualizację kroczącą, ale upewnij się, że również imagePullPolicy: "Always"ustawiłeś.

Aktualizacja:

Kolejną sztuczką, którą znalazłem, w której nie musisz zmieniać nazwy obrazu, jest zmiana wartości pola, które wyzwoli aktualizację kroczącą, na przykład terminationGracePeriodSeconds. Możesz to zrobić za pomocą kubectl edit deployment your_deploymentlub kubectl apply -f your_deployment.yamllub używając takiej łatki:

kubectl patch deployment your_deployment -p \
  '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":31}}}}'

Upewnij się tylko, że zawsze zmieniasz wartość liczbową.

AKTUALIZACJA 24.06.2019

Na podstawie komentarza @Jodiug, jeśli masz 1.15wersję, możesz użyć polecenia:

kubectl rollout restart deployment/demo

Przeczytaj więcej na ten temat:

https://github.com/kubernetes/kubernetes/issues/13488

Cóż, jest ciekawa dyskusja na ten temat w projekcie kubernetes GitHub. Zobacz problem: https://github.com/kubernetes/kubernetes/issues/33664

Z opisanych tam rozwiązań sugerowałbym jedno z dwóch.

Pierwszy

1. Przygotuj wdrożenie

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: demo
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: demo
        image: registry.example.com/apps/demo:master
        imagePullPolicy: Always
        env:
        - name: FOR_GODS_SAKE_PLEASE_REDEPLOY
          value: 'THIS_STRING_IS_REPLACED_DURING_BUILD'

2. wdrożyć

sed -ie "s/THIS_STRING_IS_REPLACED_DURING_BUILD/$(date)/g" deployment.yml
kubectl apply -f deployment.yml

Drugi (jedna wkładka):

kubectl patch deployment web -p \
  "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"date\":\"`date +'%s'`\"}}}}}"

Oczywiście imagePullPolicy: Alwaysjest to wymagane w obu przypadkach.

kubectl rollout restart deployment myapp

Jest to obecny sposób wyzwalania aktualizacji kroczącej i pozostawienia starych zestawów replik na miejscu dla innych operacji zapewnianych przez kubectl rolloutpodobne wycofywanie zmian.

Używam Gitlab-CI do budowania obrazu, a następnie wdrażam go bezpośrednio do GCK. Jeśli użyjesz zgrabnej małej sztuczki, aby uzyskać aktualizację kroczącą bez zmiany jakichkolwiek rzeczywistych ustawień kontenera, czyli zmianę etykiety na bieżącą zatwierdzoną-krótką-sha.

Moje polecenie wygląda tak:

kubectl patch deployment my-deployment -p "{\"spec\":{\"template\":{\"metadata\":{\"labels\":{\"build\":\"$CI_COMMIT_SHORT_SHA\"}}}}}}"

Gdzie możesz użyć dowolnej nazwy i dowolnej wartości dla etykiety, o ile zmienia się ona przy każdej kompilacji.

Baw się dobrze!

Wygląda na to, że k8s oczekuje od nas dostarczenia innego tagu obrazu dla każdego wdrożenia. Domyślną strategią byłoby, aby system CI generować i przesunąć obrazy Döcker, znakowanie je z numerem kompilacji: xpmatteo/foobar:456.

W przypadku lokalnego rozwoju może być wygodne użycie skryptu lub pliku makefile, takiego jak ten:

# create a unique tag    
VERSION:=$(shell date +%Y%m%d%H%M%S)
TAG=xpmatteo/foobar:$(VERSION)

deploy:
    npm run-script build
    docker build -t $(TAG) . 
    docker push $(TAG)
    sed s%IMAGE_TAG_PLACEHOLDER%$(TAG)% foobar-deployment.yaml | kubectl apply -f - --record

sedKomenda zastępuje zastępczy w dokumencie rozmieszczania z rzeczywistego obrazu generowanego tagu.

Używam Azure DevOps do wdrażania aplikacji w kontenerach, łatwo mogę rozwiązać ten problem, używając identyfikatora kompilacji

Za każdym razem, gdy kompiluje i generuje nowy identyfikator kompilacji, używam tego identyfikatora kompilacji jako tagu dla obrazu dockera, na przykład

nazwa zdjęcia: buildID

po pomyślnym zbudowaniu obrazu (CI) w potoku CD w pliku yml wdrożenia mam nadać nazwę obrazu jako

nazwa zdjęcia: env: buildID

tutaj evn: buildid jest zmienną Azure Devops, która ma wartość identyfikatora kompilacji.

więc teraz za każdym razem, gdy mam nowe zmiany do kompilacji (CI) i wdrożenia (CD).

prosimy o komentarz, jeśli potrzebujesz definicji kompilacji dla CI / CD.