mirror of
https://github.com/kubernetes-sigs/kustomize.git
synced 2026-06-14 02:20:53 +00:00
64 lines
3.1 KiB
Markdown
64 lines
3.1 KiB
Markdown
# Pseudo k8s
|
||
|
||
[kubernetes/api]: https://github.com/kubernetes/api
|
||
[kubernetes/apimachinery]: https://github.com/kubernetes/apimachinery
|
||
[kubernetes/client-go]: https://github.com/kubernetes/client-go
|
||
[init-pseudo-module.sh]: init-pseudo-module.sh
|
||
|
||
The module defined below in `pseudo/k8s` contains code generated by the
|
||
[init-pseudo-module.sh] script.
|
||
|
||
The module contains clones (see the [script][init-pseudo-module.sh] for the specific clone tag) of code from the following repositories:
|
||
|
||
- [kubernetes/api]
|
||
- [kubernetes/apimachinery]
|
||
- [kubernetes/client-go]
|
||
|
||
These repositories are in turn snapshots of code being developed
|
||
in [kubernetes staging](https://github.com/kubernetes/kubernetes/tree/master/staging).
|
||
|
||
## Why?
|
||
|
||
[`cli-runtime`]: https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/cli-runtime
|
||
[`apimachinery`]: https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/apimachinery
|
||
|
||
In what follows, let the word `apimachinery` generally represent one of more of the modules [kubernetes/api], [kubernetes/apimachinery], [kubernetes/client-go].
|
||
|
||
- kubectl depends on `apimachinery` in the k/k repo via a `go.mod` replacement.
|
||
|
||
- kubectl must depend the on kustomize API module.
|
||
|
||
- `apimachinery` doesn’t yet do releases distinguished by major version number. I.e., one cannot write a `go.mod` file containing the lines
|
||
> ```
|
||
> require k8s.io/apimachinery v1.1.4
|
||
> require k8s.io/apimachinery/v2 v2.1.0
|
||
> require k8s.io/apimachinery/v3 v3.2.1
|
||
> ```
|
||
The only option at this time are pseudo-versions of the form `v0.0.0-20181127025237-2b1284ed4c93` and everything in the k/k repo must depend on exactly one pseudo version, which is typically a v.0.0.0 with a replace directive specifying an in-repo relative path.
|
||
|
||
- kustomize depends on `apimachinery`.
|
||
|
||
This creates a problem, since kubectl and kustomize have no means to declare a dependence on different versions of `apimachinery`, and no means to sync on the same version since kubectl and kustomize live in different repositories.
|
||
|
||
A solution to this is a _manual vendor_: either the kustomize API module source code must be manually snapshotted into the k/k repo at some invented path that could never be confused with a normal module import path, or the `apimachinery` module (and friends) must be snapshotted into the kustomize repo using the same notion of import path replacement.
|
||
|
||
This module is the result of taking the latter option. kustomize can depend on this snapshot of `apimachinery`, and both can be vendored into the k/k repo safely.
|
||
|
||
|
||
## Caveats
|
||
|
||
This pseudo k8s module may be removed at anytime in the future without warning and no
|
||
support will be given for these modules.
|
||
It's best to try to encourage semver development in `apimachinery` directly.
|
||
|
||
## How was this module made?
|
||
|
||
These libraries were forked by running `git clone` to clone the repos.
|
||
|
||
### Automated Creation Steps
|
||
|
||
1. Remove the current existing pseudo modules
|
||
- `$ rm -rf pseudo/k8s`
|
||
2. Run the [init-pseudo-module.sh](init-pseudo-module.sh) script to clone and configure pseudo deps
|
||
- From the root directory -- `$ pseudo/init-pseudo-module.sh`
|