Кубернатс с: последняя проблема с изображением

Question

Я использую Kubernates для производственной среды (я новичок в такого рода конфигурации). Это пример для одного из моих файлов деполяции (с изменениями):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myProd
  labels:
    app: thisIsMyProd
spec:
  replicas: 3
  selector:
    matchLabels:
      app: thisIsMyProd
  template:
    metadata:
      labels:
        app: thisIsMyProd
    spec:
      containers:
        - name: myProd
          image: DockerUserName/MyProdProject  # <==== Latest
          ports:
           - containerPort: 80

Теперь я хотел, чтобы он работал с travis ci, поэтому я сделал что-то похожее на это:

sudo: required

services:
  - docker

env:
  global:
    - LAST_COMMIT_SHA=$(git rev-parse HEAD)
    - SERVICE_NAME=myProd
    - DOCKER_FILE_PATH=.
    - DOCKER_CONTEXT=.

addons:
  apt:
    packages:
      - sshpass

before_script:
  - docker build -t $SERVICE_NAME:latest -f $DOCKER_FILE_PATH $DOCKER_CONTEXT

script:
  # Mocking run test cases

deploy:
  - provider: script
    script: bash ./deployment/deploy-production.sh
    on:
      branch: master

И, наконец, вот скрипт deploy-production.sh:

#!/usr/bin/env bash

# Log in to the docker CLI
echo "$DOCKER_PASSWORD" | docker login -u "$DOCKER_USERNAME" --password-stdin

# Build images
docker build -t $DOCKER_USERNAME/$SERVICE_NAME:latest -t $DOCKER_USERNAME/$SERVICE_NAME:$LAST_COMMIT_SHA -f $DOCKER_FILE_PATH $DOCKER_CONTEXT

# Take those images and push them to docker hub
docker push $DOCKER_USERNAME/$SERVICE_NAME:latest
docker push $DOCKER_USERNAME/$SERVICE_NAME:$LAST_COMMIT_SHA

# Run deployment script in deployment machine
export SSHPASS=$DEPLOYMENT_HOST_PASSWORD
ssh-keyscan -H $DEPLOYMENT_HOST >> ~/.ssh/known_hosts

# Run Kubectl commands
kubctl apply -f someFolder
kubctl set image ... # instead of the `...` the rest command that sets the image with SHA to the deployments

Теперь вот мои вопросы:

1. Когда travis fini sh его работа, скрипт deploy-production.sh с run, когда речь идет о слиянии с веткой master, Теперь у меня есть беспокойство по поводу шага kubectl, при первом развертывании, когда мы apply развернем, он будет pull image из dockerhup и попытается запустить их, после этого команда set image запустит изменение образа эти деполяции. Будет ли это делать развертывание дважды?

2. Когда я попытался развернуть во второй раз, я заметил, что развертывание использовало старую версию из latest образа, потому что он нашел его локально , После поиска я нашел imagePullPolicy и установил always. Но представьте, что я не использовал этот атрибут imagePullPolicy, что бы на самом деле произошло в этом случае? Я знаю, что контейнеры кода старой версии для первой команды apply. Но разве установленный образ не исправит это? Чтобы прояснить мой вопрос, использует ли kubernetes какой-то случайный способ для выбора стручков, которые идут на go вниз? Как будто он не помечает стручки в порядке, в котором выполняются команды, поэтому он обнаружит, что установленные стручки изображений должны остаться, а стручки apply должны быть прерваны?

3. Не тянет ли каждый раз вредно? Должен ли я всегда делать образ развертывания каким-то образом, чтобы не использовать latest, лучше стереть эту неприятность?

Спасибо

Answer 1

1. Если тег изображения одинаков как в apply, так и в set image, то только действие apply повторно развертывает развертывание (в этом случае вам не нужна команда set image ). Если они ссылаются на разные теги изображений, то да, развертывание будет выполнено дважды.

2. Если вы используете тег latest, применяете манифест, который использует тег latest без изменений НЕ будет повторно развертывать развертывание. Вам необходимо внести изменения в файл манифеста, чтобы заставить Kubernetes переустанавливаться. Как и в моем случае, я использую команду date для генерации переменной TIMESTAMP, которая передается как в env spe c контейнера pod, который мой контейнер не использует никоим образом, просто для принудительного Развертывание Развертывания. Или вы также можете использовать kubectl rollout restart deployment/name, если вы используете Kubernetes 1.15 или более поздней версии.

3. За исключением потраченной пропускной способности или если вы платите за то, сколько раз вы тянете изображение docker (бедный вы), нет никакого вреда с дополнительным извлечением изображения, просто чтобы убедиться, что вы используете последнюю версию изображения. Даже если вы используете указанный c тег изображения с номерами версий, такими как 1.10.112-rc5, это будет случай, когда вы или ваши коллеги-разработчики забудут обновить номер версии при нажатии измененной версии изображения. ИМХО, imagePullPolicy=always должно быть значением по умолчанию, а не явным образом.