|
1 | 1 | apiVersion: apiextensions.k8s.io/v1beta1
|
2 | 2 | kind: CustomResourceDefinition
|
3 | 3 | metadata:
|
| 4 | + creationTimestamp: null |
4 | 5 | labels:
|
5 | 6 | controller-tools.k8s.io: "1.0"
|
6 | 7 | name: machines.cluster.k8s.io
|
@@ -40,72 +41,180 @@ spec:
|
40 | 41 | openAPIV3Schema:
|
41 | 42 | properties:
|
42 | 43 | apiVersion:
|
| 44 | + description: 'APIVersion defines the versioned schema of this representation |
| 45 | + of an object. Servers should convert recognized schemas to the latest |
| 46 | + internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#resources' |
43 | 47 | type: string
|
44 | 48 | kind:
|
| 49 | + description: 'Kind is a string value representing the REST resource this |
| 50 | + object represents. Servers may infer this from the endpoint the client |
| 51 | + submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#types-kinds' |
45 | 52 | type: string
|
46 | 53 | metadata:
|
47 | 54 | type: object
|
48 | 55 | spec:
|
49 |
| - type: object |
50 | 56 | properties:
|
51 | 57 | configSource:
|
| 58 | + description: To populate in the associated Node for dynamic kubelet |
| 59 | + config. This field already exists in Node, so any updates to it in |
| 60 | + the Machine spec will be automatically copied to the linked NodeRef |
| 61 | + from the status. The rest of dynamic kubelet config support should |
| 62 | + then work as-is. |
52 | 63 | type: object
|
53 | 64 | metadata:
|
| 65 | + description: This ObjectMeta will autopopulate the Node created. Use |
| 66 | + this to indicate what labels, annotations, name prefix, etc., should |
| 67 | + be used when creating the Node. |
54 | 68 | type: object
|
55 | 69 | providerSpec:
|
| 70 | + description: Provider-specific configuration to use during node creation. |
56 | 71 | properties:
|
57 | 72 | value:
|
| 73 | + description: Value is an inlined, serialized representation of the |
| 74 | + resource configuration. It is recommended that providers maintain |
| 75 | + their own versioned API types that should be serialized/deserialized |
| 76 | + from this field, akin to component config. |
58 | 77 | type: object
|
59 | 78 | valueFrom:
|
| 79 | + description: Source for the provider configuration. Cannot be used |
| 80 | + if value is not empty. |
60 | 81 | properties:
|
61 | 82 | machineClass:
|
| 83 | + description: The machine class from which the provider config |
| 84 | + should be sourced. |
62 | 85 | properties:
|
63 | 86 | provider:
|
| 87 | + description: Provider is the name of the cloud-provider |
| 88 | + which MachineClass is intended for. |
64 | 89 | type: string
|
65 | 90 | type: object
|
66 | 91 | type: object
|
67 | 92 | type: object
|
68 | 93 | taints:
|
| 94 | + description: The full, authoritative list of taints to apply to the |
| 95 | + corresponding Node. This list will overwrite any modifications made |
| 96 | + to the Node on an ongoing basis. |
69 | 97 | items:
|
70 | 98 | type: object
|
71 | 99 | type: array
|
72 | 100 | versions:
|
| 101 | + description: Versions of key software to use. This field is optional |
| 102 | + at cluster creation time, and omitting the field indicates that the |
| 103 | + cluster installation tool should select defaults for the user. These |
| 104 | + defaults may differ based on the cluster installer, but the tool should |
| 105 | + populate the values it uses when persisting Machine objects. A Machine |
| 106 | + spec missing this field at runtime is invalid. |
73 | 107 | properties:
|
74 | 108 | controlPlane:
|
| 109 | + description: Semantic version of the Kubernetes control plane to |
| 110 | + run. This should only be populated when the machine is a master. |
75 | 111 | type: string
|
76 | 112 | kubelet:
|
| 113 | + description: Semantic version of kubelet to run |
77 | 114 | type: string
|
78 | 115 | required:
|
79 | 116 | - kubelet
|
80 | 117 | type: object
|
81 | 118 | required:
|
82 | 119 | - providerSpec
|
| 120 | + type: object |
83 | 121 | status:
|
84 | 122 | properties:
|
85 | 123 | addresses:
|
| 124 | + description: Addresses is a list of addresses assigned to the machine. |
| 125 | + Queried from cloud provider, if available. |
86 | 126 | items:
|
87 | 127 | type: object
|
88 | 128 | type: array
|
89 | 129 | conditions:
|
| 130 | + description: 'List of conditions synced from the node conditions of |
| 131 | + the corresponding node-object. Machine-controller is responsible for |
| 132 | + keeping conditions up-to-date. MachineSet controller will be taking |
| 133 | + these conditions as a signal to decide if machine is healthy or needs |
| 134 | + to be replaced. Refer: https://kubernetes.io/docs/concepts/architecture/nodes/#condition' |
90 | 135 | items:
|
91 | 136 | type: object
|
92 | 137 | type: array
|
93 | 138 | errorMessage:
|
94 | 139 | type: string
|
95 | 140 | errorReason:
|
| 141 | + description: In the event that there is a terminal problem reconciling |
| 142 | + the Machine, both ErrorReason and ErrorMessage will be set. ErrorReason |
| 143 | + will be populated with a succinct value suitable for machine interpretation, |
| 144 | + while ErrorMessage will contain a more verbose string suitable for |
| 145 | + logging and human consumption. These fields should not be set for |
| 146 | + transitive errors that a controller faces that are expected to be |
| 147 | + fixed automatically over time (like service outages), but instead |
| 148 | + indicate that something is fundamentally wrong with the Machine's |
| 149 | + spec or the configuration of the controller, and that manual intervention |
| 150 | + is required. Examples of terminal errors would be invalid combinations |
| 151 | + of settings in the spec, values that are unsupported by the controller, |
| 152 | + or the responsible controller itself being critically misconfigured. Any |
| 153 | + transient errors that occur during the reconciliation of Machines |
| 154 | + can be added as events to the Machine object and/or logged in the |
| 155 | + controller's output. |
96 | 156 | type: string
|
| 157 | + lastOperation: |
| 158 | + description: LastOperation describes the last-operation performed by |
| 159 | + the machine-controller. This API should be useful as a history in |
| 160 | + terms of the latest operation performed on the specific machine. It |
| 161 | + should also convey the state of the latest-operation for example if |
| 162 | + it is still on-going, failed or completed successfully. |
| 163 | + properties: |
| 164 | + description: |
| 165 | + description: Description is the human-readable description of the |
| 166 | + last operation. |
| 167 | + type: string |
| 168 | + lastUpdated: |
| 169 | + description: LastUpdateTime is the timestamp at which LastOperation |
| 170 | + API was last-updated. |
| 171 | + format: date-time |
| 172 | + type: string |
| 173 | + state: |
| 174 | + description: State is the current status of the last performed operation. |
| 175 | + E.g. Processing, Failed, Successful etc |
| 176 | + type: string |
| 177 | + type: |
| 178 | + description: Type is the type of operation which was last performed. |
| 179 | + E.g. Create, Delete, Update etc |
| 180 | + type: string |
| 181 | + type: object |
97 | 182 | lastUpdated:
|
| 183 | + description: When was this status last observed |
98 | 184 | format: date-time
|
99 | 185 | type: string
|
100 | 186 | nodeRef:
|
| 187 | + description: If the corresponding Node exists, this will point to its |
| 188 | + object. |
101 | 189 | type: object
|
| 190 | + phase: |
| 191 | + description: Phase represents the current phase of machine actuation. |
| 192 | + E.g. Pending, Running, Terminating, Failed etc. |
| 193 | + type: string |
102 | 194 | providerStatus:
|
| 195 | + description: Provider-specific status. It is recommended that providers |
| 196 | + maintain their own versioned API types that should be serialized/deserialized |
| 197 | + from this field. |
103 | 198 | type: object
|
104 | 199 | versions:
|
| 200 | + description: 'The current versions of software on the corresponding |
| 201 | + Node (if it exists). This is provided for a few reasons: 1) It is |
| 202 | + more convenient than checking the NodeRef, traversing it to the |
| 203 | + Node, and finding the appropriate field in Node.Status.NodeInfo (which |
| 204 | + uses different field names and formatting). 2) It removes some of |
| 205 | + the dependency on the structure of the Node, so that if the structure |
| 206 | + of Node.Status.NodeInfo changes, only machine controllers need |
| 207 | + to be updated, rather than every client of the Machines API. 3) |
| 208 | + There is no other simple way to check the ControlPlane version. |
| 209 | + A client would have to connect directly to the apiserver running |
| 210 | + on the target node in order to find out its version.' |
105 | 211 | properties:
|
106 | 212 | controlPlane:
|
| 213 | + description: Semantic version of the Kubernetes control plane to |
| 214 | + run. This should only be populated when the machine is a master. |
107 | 215 | type: string
|
108 | 216 | kubelet:
|
| 217 | + description: Semantic version of kubelet to run |
109 | 218 | type: string
|
110 | 219 | required:
|
111 | 220 | - kubelet
|
|
0 commit comments