如何在Kubernetes卷中使用Skaffold？

Question

我有一个python应用程序，其docker build大约需要15-20分钟。 这是我的Dockerfile看起来或多或少的样子

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

现在，如果我使用skaffold，则任何代码更改都会触发重建，并且它将重新安装所有需求（从COPY步骤开始，所有其他需求都将被重建），无论它们是否已经安装。 在泊坞窗中，使用卷即可解决此问题。 在kubernetes中，如果我们以以下方式使用卷：

apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- image: test:test
name: test-container
volumeMounts:
- mountPath: /usr/local/venv # this is the directory of the 
# virtualenv of python
    name: test-volume
volumes:
- name: test-volume
  awsElasticBlockStore:
    volumeID: <volume-id>
    fsType: ext4

skaffold是否可以解决此额外要求？

Answer 1

我不能专门为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 ）可用。

Answer 2

skaffold的答案是一个很好的最佳实践（+1） skaffold本身并不能解决底层的层缓存失效问题，这导致必须在每次构建过程中重新安装需求。

为了提高性能，您可以将所有python软件包缓存在您的pod中安装的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还可以使用kaniko-warmer将基本映像缓存到永久磁盘上，例如：

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

在pod中运行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: {}

Answer 3

如果您的目标是加快开发过程：您不必每次更改一行代码就触发一个全新的部署过程，而是可以切换到基于同步的开发过程进行一次部署，然后更新正在运行的容器中的文件编辑代码时。

如果在本地计算机上更改文件， Skaffold支持文件同步以直接更新已部署容器内的文件 。 但是，文档状态为“文件同步为Alpha”（ https://skaffold.dev/docs/how-tos/filesync/ ），我完全同意在一段时间前使用它：同步机制只是单向的（没有从容器同步回本地）和相当多的错误，即，当切换git分支，安装依赖项等时，它经常崩溃，这可能很烦人。

如果您想更轻松地开始基于同步的Kubernetes开发的替代方案 ，请查看DevSpace： https : //github.com/devspace-cloud/devspace

我是DevSpace的维护者之一，因此开始了这个项目，因为Skaffold对我们的团队来说太慢了，那时还没有文件同步。