Я не могу говорить конкретно о skaffold, но сборку образа контейнера можно улучшить. Если доступно кэширование слоев, переустанавливайте зависимости только при изменении requirements.txt. Это задокументировано в передовых методах «ДОБАВИТЬ или КОПИРОВАТЬ».

FROM ubuntu:18.04
...
COPY requirements.txt /usr/local/app/
RUN pip install -r /usr/local/app/requirements.txt
COPY . /usr/local/app
...
CMD ...

Вам может потребоваться запускать обновления несколько раз, если версии модуля определены слабо и говорят, что вам нужна новая версия патча. Я обнаружил, что требования должны быть конкретными, чтобы версии не попадали под ваше приложение без вашего знания / тестирования.

Kaniko строит в кластере

Чтобы сборки kaniko использовали кеш в кластере, где по умолчанию нет постоянного хранилища, для kaniko требуется либо смонтированный постоянный том (--cache-dir), либо репозиторий образа контейнера (--cache-repo) с доступными слоями.

Если ваша цель - ускорить процесс разработки: вместо того, чтобы запускать совершенно новый процесс развертывания каждый раз, когда вы меняете строку кода, вы можете переключиться на процесс разработки на основе синхронизации, чтобы развернуть его один раз, а затем обновить файлы в запущенных контейнерах. при редактировании кода.

Skaffold поддерживает синхронизацию файлов для непосредственного обновления файлов внутри развернутых контейнеров, если вы измените их на своем локальном компьютере. Однако в документации указано, что «Синхронизация файлов - альфа» (https://skaffold.dev/docs/how-tos/filesync/), и я могу полностью согласиться с тем, чтобы работать с ним некоторое время назад: механизм синхронизации только однонаправленный (нет синхронизации из контейнера обратно в локальный) и довольно глючный, т.е. он часто дает сбой при переключении веток git, установке зависимостей и т. д., что может сильно раздражать.

Если вам нужна более стабильная альтернатива для разработки Kubernetes на основе синхронизации, с которой очень легко начать, взгляните на DevSpace: https://github.com/devspace-cloud/devspace

Я являюсь одним из сопровождающих DevSpace и начал этот проект, потому что Скаффолд был слишком медленным для нашей команды и тогда у него не было синхронизации файлов.

ответ от @ Matt - отличная передовая практика (+1) - skaffold сам по себе не решит проблему с кешем нижележащего уровня. проблемы с аннулированием, которые приводят к необходимости переустанавливать требования во время каждой сборки.

Для повышения производительности вы можете кэшировать все python пакеты в volume, установленном в вашем модуле, например:

apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- image: test:test
  name: test-container
volumeMounts:
- mountPath: /usr/local/venv
    name: test-volume
- mountPath: /root/.cache/pip
    name: pip-cache
volumes:
- name: test-volume
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4
- name: pip-cache
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

Таким образом, если кеш сборки когда-либо станет недействительным и вам придется переустановить requirements.txt, вы сэкономите время, загрузив их из кеша.

Если вы создаете с помощью kaniko, вы также можете кэшировать базовые изображения на постоянный диск с помощью kaniko-warmer, для пример:

...
volumeMounts:
...
- mountPath: /cache
    name: kaniko-warmer
volumes:
...
- name: kaniko-warmer
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

Запуск kaniko-warmer внутри модуля: docker run --rm -it -v /cache:/cache --entrypoint /kaniko/warmer gcr.io/kaniko-project/warmer --cache-dir=/cache --image=python:3.7-slim --image=nginx:1.17.3. Ваш skaffold.yaml может выглядеть примерно так:

apiVersion: skaffold/v1beta13
kind: Config
build:
  artifacts:
  - image: test:test
    kaniko:
      buildContext:
        localDir: {}
      cache:
        hostPath: /cache
  cluster:
    namespace: jx
    dockerConfig:
      secretName: jenkins-docker-cfg
  tagPolicy:
    envTemplate:
      template: '{{.DOCKER_REGISTRY}}/{{.IMAGE_NAME}}'
deploy:
  kubectl: {}