Kaniko集群内部构建

Question

我有一个python应用程序，其docker构建大约需要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更改时重新安装依赖项。记录在“添加或复制” Best Practices中。

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

@Matt的answer是一个很好的最佳实践（+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-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: {}

Answer 3

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

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

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

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

如何将Skaffold与kubernetes卷一起使用？

3 个答案:

Kaniko集群内部构建