Automatic merge from submit-queue (batch tested with PRs 63445, 63820). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. core v1: deprecate the gitRepo volume type gitRepo stopped accepting new features nearly 2 years ago https://github.com/kubernetes/kubernetes/issues/17676#issuecomment-228650586 and today this behavior can easily be achieved through an init container. The kubelet shelling out to git in the host namespace can also be a security issue on un-trusted repos, as was demonstrated by [CVE-2017-1000117](https://groups.google.com/forum/#!topic/kubernetes-announce/CTLXJ74cu8M). Our own documentation even alludes to this volume type being removed in the future: > In the future, such volumes may be moved to an even more decoupled model, rather than extending the Kubernetes API for every such use case. https://kubernetes.io/docs/concepts/storage/volumes/#gitrepo Closes https://github.com/kubernetes/kubernetes/issues/60999 ```release-note-action-required The GitRepo volume type is deprecated. To provision a container with a git repo, mount an EmptyDir into an InitContainer that clones the repo using git, then mount the EmptyDir into the Pod's container. ``` /release-note-action-required Instead of this: ```yaml apiVersion: v1 kind: Pod metadata: name: server spec: containers: - image: nginx name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume gitRepo: repository: "git@somewhere:me/my-git-repository.git" revision: "22f1d8406d464b0c0874075539c1f2e96c253775" ``` Do this: ```yaml apiVersion: v1 kind: ConfigMap metadata: name: git-clone data: git-clone.sh: | #!/bin/sh -e git clone $1 $3 cd $3 git reset --hard $2 --- apiVersion: v1 kind: Pod metadata: name: server spec: initContainers: - name: git-clone image: alpine/git # Any image with git will do command: - /usr/local/git/git-clone.sh args: - "https://somewhere/me/my-git-repository.git" - "22f1d8406d464b0c0874075539c1f2e96c253775" - "/mypath" volumeMounts: - name: git-clone mountPath: /usr/local/git - name: git-repo mountPath: /mypath containers: - image: nginx name: nginx volumeMounts: - mountPath: /mypath name: git-volume volumes: - name: git-volume emptyDir: {} - name: git-clone configMap: name: git-clone defaultMode: 0755 ```
External Repository Staging Area
This directory is the staging area for packages that have been split to their own repository. The content here will be periodically published to respective top-level k8s.io repositories.
Repositories currently staged here:
k8s.io/apiextensions-apiserverk8s.io/apik8s.io/apimachineryk8s.io/apiserverk8s.io/client-gok8s.io/kube-aggregatork8s.io/code-generatork8s.io/metricsk8s.io/sample-apiserverk8s.io/sample-controller
The code in the staging/ directory is authoritative, i.e. the only copy of the code. You can directly modify such code.
Using staged repositories from Kubernetes code
Kubernetes code uses the repositories in this directory via symlinks in the
vendor/k8s.io directory into this staging area. For example, when
Kubernetes code imports a package from the k8s.io/client-go repository, that
import is resolved to staging/src/k8s.io/client-go relative to the project
root:
// pkg/example/some_code.go
package example
import (
"k8s.io/client-go/dynamic" // resolves to staging/src/k8s.io/client-go/dynamic
)
Once the change-over to external repositories is complete, these repositories
will actually be vendored from k8s.io/<package-name>.