You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -71,7 +57,7 @@ By standardizing on a container format for this data, we get many other features
71
57
We would like to make a distinction between:
72
58
73
59
***Manifests** * data which can be applied to a cluster, either with or without pre-processing. Examples: json or yaml manifests, helm charts, kustomize bundles.
74
-
***Metadata** * information which will not be directly applied to a cluster, but which will otherwise affect the processing or application of a bundle.
60
+
***Metadata** * information which will not be directly applied to a cluster, but which will otherwise affect the processing or application of a bundle.
75
61
76
62
## User Stories
77
63
@@ -85,14 +71,14 @@ Constraints:
85
71
86
72
## Implementation Details/Notes/Constraints
87
73
88
-
The initial implementation target will be Docker v2-2 manifests, manifest-lists, and client support, for maximum compatibility with existing tooling. OCI is a future target, but avoided for now due to lack of tooling support.
74
+
The initial implementation target will be Docker v2-2 manifests, manifest-lists, and client support, for maximum compatibility with existing tooling. OCI is a future target, but avoided for now due to lack of tooling support.
89
75
90
76
Labels are used to identify the contents. The approach is similar to OCI mediatypes, but is supported by existing tooling.
91
77
92
78
The following label convention is used to annotate the bundle image:
93
79
94
80
*`<namespace>.mediatype.<version>=<identifier>` is used to identify the top-level format of the bundle. For example, this may indicate that the bundle contains a kustomization file and kustomize manifests.
95
-
*`<namespace>.bundle.manifests.<version>=<path>` reflects the path in the image to a directory that contains manifests.
81
+
*`<namespace>.bundle.manifests.<version>=<path>` reflects the path in the image to a directory that contains manifests.
96
82
*`<namespace>.bundle.metadata.<version>=<path>` reflects the path in the image to a directory that contains metadata.
97
83
* Any additional `<namespace>.bundle.<identifier>=<value>` may be used to indicate additional properties of the manifest bundle. It may be useful to denormalize information that would otherwise be stored in the metadata directory, so that tooling can read it without unpacking a full image.
98
84
These labels should also be replicated in a well-known location within the image, metadata/annotations.yaml:
Copy file name to clipboardExpand all lines: keps/sig-cluster-lifecycle/image-builder/2497-Kubernetes-Image-Builder/README.md
+14-34Lines changed: 14 additions & 34 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,23 +1,3 @@
1
-
---
2
-
title: Kubernetes Image Builder
3
-
authors:
4
-
- "@timothysc"
5
-
- "@moshloop"
6
-
owning-sig: sig-cluster-lifecycle
7
-
reviewers:
8
-
- "@justinsb"
9
-
- "@luxas"
10
-
- "@astrieanna"
11
-
approvers:
12
-
- "@justinsb"
13
-
- "@timothysc"
14
-
- "@luxas"
15
-
editor: "@timothysc"
16
-
creation-date: 2019-06-11
17
-
last-updated: 2019-07-05
18
-
status: provisional
19
-
---
20
-
21
1
# Kubernetes Image Builder
22
2
23
3
## Table of Contents
@@ -40,14 +20,14 @@ status: provisional
40
20
<!-- /toc -->
41
21
42
22
## Summary
43
-
It is common for modern cloud based software deployments to follow immutable patterns. One of the foundational pieces to this idea is the creation of immutable images. There are already several tools that create images in the Kubernetes ecosystem, which include: [Wardroom](https://github.com/heptiolabs/wardroom), [Cluster API AWS](https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/master/Makefile), [Cluster API vSphere](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/master/Makefile), [amazon-eks-ami](https://github.com/awslabs/amazon-eks-ami), [talos](https://docs.talos-systems.com/), [LinuxKit](https://github.com/linuxkit/linuxkit),[kube-deploy](https://github.com/kubernetes/kube-deploy/tree/master/imagebuilder), etc. The purpose of this proposal is to distill down the common requirements and provide an image building utility that can be leveraged by the Kubernetes ecosystem.
23
+
It is common for modern cloud based software deployments to follow immutable patterns. One of the foundational pieces to this idea is the creation of immutable images. There are already several tools that create images in the Kubernetes ecosystem, which include: [Wardroom](https://github.com/heptiolabs/wardroom), [Cluster API AWS](https://github.com/kubernetes-sigs/cluster-api-provider-aws/blob/master/Makefile), [Cluster API vSphere](https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/blob/master/Makefile), [amazon-eks-ami](https://github.com/awslabs/amazon-eks-ami), [talos](https://docs.talos-systems.com/), [LinuxKit](https://github.com/linuxkit/linuxkit),[kube-deploy](https://github.com/kubernetes/kube-deploy/tree/master/imagebuilder), etc. The purpose of this proposal is to distill down the common requirements and provide an image building utility that can be leveraged by the Kubernetes ecosystem.
44
24
45
-
The purpose of this document is to request the creation of a sub-project of sig-cluster-lifecycle to address this space.
25
+
The purpose of this document is to request the creation of a sub-project of sig-cluster-lifecycle to address this space.
46
26
47
27
## Motivation
48
28
There exists a need to be able to create repeatable IaaS images across providers for the explicit purpose of being able to deploy a Kubernetes cluster.
49
29
50
-
### Goals
30
+
### Goals
51
31
* To build images for Kubernetes-conformant clusters in a consistent way across infrastructures, providers, and business needs.
52
32
* Install all software, containers, and configuration needed to pass conformance tests.
53
33
* Support end users requirements to customize images for their business needs.
@@ -57,7 +37,7 @@ There exists a need to be able to create repeatable IaaS images across providers
57
37
* To ensure that the creation of images is performed via well defined phases. Where users could choose specific phases that they needed.
58
38
* Support incremental usage.
59
39
60
-
### Non-Goals
40
+
### Non-Goals
61
41
* To publish images to cloud provider marketplaces, or to provide software workflow to automatically upload the built images on the cloud provider infrastructure.
62
42
* For example, it is not the responsibility of *this* utility to publish images to Amazon Marketplace. Each Cluster API Provider may implement its own image publisher. Users should be able to use the provider's publisher with the image output by the image builder.
63
43
* To provide upgrade or downgrade semantics.
@@ -66,14 +46,14 @@ There exists a need to be able to create repeatable IaaS images across providers
66
46
* To create images from scratch.
67
47
* The purpose of the tool is to take an existing image and make it Kubernetes ready.
68
48
69
-
## Proposal
49
+
## Proposal
70
50
The Image Builder will start from one image in a supported format and create a new image in the same format specifically for the purpose of creating Kubernetes clusters. In surveying the landscape of tooling it becomes readily apparent that there are a plethora of tools that provide an opinionated end-to-end user story around image creation, but we’ve observed it can be decomposed into a series of steps, or phases. By decomposing the problem we can provide a rallying point for different tools to integrate, and provide the Kubernetes ecosystem with a common utility and user experience across those tools.
71
51
72
52
As a precondition the Image Builder will require a bootable disk image as an input, with native support for the cloud images published by the supported distributions. However any external process or tool can be used to create the initial disk image from other sources including [ISO](https://packer.io)’s, file trees and [docker](https://github.com/iximiuz/docker-to-linux) images. Existing disk images can also be customized using tools like [virt-customize](http://libguestfs.org/virt-customize.1.html) before being fed into the Image Builder.
73
53
74
-
**NOTE:** It should be noted that this document is intentionally high level and purposefully omits design choices which should be made at a later date once the subproject is further along in its lifecycle.
54
+
**NOTE:** It should be noted that this document is intentionally high level and purposefully omits design choices which should be made at a later date once the subproject is further along in its lifecycle.
75
55
76
-
### Phases
56
+
### Phases
77
57
#### Phase 0 (Base Image)
78
58
79
59
Lay down the initial base image. Often times this can be some form of certified base image from a vendor or IT team. **NOTE:** It is not a goal of this project to take on creation of those initial images.
@@ -96,7 +76,7 @@ Phase 0 will kickoff Phase 1, for example by chrooting into the disk or using ne
The purpose of this phase would be the installation of the Kubernetes stack, default account setup, updating packages, config, etc.
79
+
The purpose of this phase would be the installation of the Kubernetes stack, default account setup, updating packages, config, etc.
100
80
101
81
**Input:** / with root/sudo access and a known package manager
102
82
@@ -107,22 +87,22 @@ The purpose of this phase would be the installation of the Kubernetes stack, def
107
87
Produce output artifacts in their final form, and ideally this should include a BOM.
108
88
109
89
### Risks and Mitigations
110
-
Given that there are already a plethora of existing solutions in the ecosystem the risk to the community is small, and this would allow contributors to help refine the best practices as they see them. In the case where the subproject does not see traction we will orphan the subproject to the kubernetes-retired org.
90
+
Given that there are already a plethora of existing solutions in the ecosystem the risk to the community is small, and this would allow contributors to help refine the best practices as they see them. In the case where the subproject does not see traction we will orphan the subproject to the kubernetes-retired org.
111
91
112
-
## Graduation Criteria
92
+
## Graduation Criteria
113
93
alpha: Adoption across Cluster API providers.
114
94
115
95
(post-alpha criteria will be added post-alpha)
116
96
117
97
## Implementation History
118
-
KEP created - Jun 12 2019
119
-
Vote approved - Jul 02 2019
98
+
KEP created - Jun 12 2019
99
+
Vote approved - Jul 02 2019
120
100
121
101
122
102
## Infrastructure Needed
123
-
None at this time, but it's possible this tool could become a critical piece of the test-automation for kubernetes, or Cluster API.
103
+
None at this time, but it's possible this tool could become a critical piece of the test-automation for kubernetes, or Cluster API.
124
104
125
105
We are requesting to be a subproject under sig-cluster-lifecycle.
126
106
127
-
## Alternatives
107
+
## Alternatives
128
108
Prior to this KEP a Cluster API workstream had written a [document](https://docs.google.com/document/d/1N65N1vCVa5QmU4BJXeSOImgRE8aq7daWhHt7XE9WCeI/edit?ts=5cde5f47#) outlining several options.
0 commit comments