-
Notifications
You must be signed in to change notification settings - Fork 225
Machine class #659
Machine class #659
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -107,7 +107,24 @@ type ProviderConfig struct { | |
// ProviderConfigSource represents a source for the provider-specific | ||
// node configuration. | ||
type ProviderConfigSource struct { | ||
// TODO(roberthbailey): Fill these in later | ||
|
||
// No more than one of the following may be specified. | ||
|
||
// The machine class from which the provider config should be sourced. | ||
// +optional | ||
MachineClass *MachineClassRef `json:machineClass,omitempty` | ||
} | ||
|
||
type MachineClassRef struct { | ||
// The name of the MachineClass. | ||
Name string `json:name` | ||
|
||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about namespace? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Storage classes aren't namespaced, and I used that same pattern here. But it's worth discussing whether they should be part of a namespace. |
||
// Parameters allow basic substitution to be applied to | ||
// a MachineClass (where supported). | ||
// Keys must not be empty. The maximum number of | ||
// parameters is 512, with a cumulative max size of 256K. | ||
// +optional | ||
Parameters map[string]string `json:parameters,omitempty` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What kinds of things is this meant to override? Capacity? Allocatable? Or stuff in the provider config? All of these seem like they could be deeply nested structures that a map would not be able to fully express. If ProviderConfig, perhaps we consider json patches? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. My thinking was in the provider config (e.g. parameterize the zone of a class to stamp out identical machine sets in multiple zones). |
||
} | ||
|
||
// MachineStatus defines the observed state of Machine | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
|
||
/* | ||
Copyright 2018 The Kubernetes Authors. | ||
|
||
Licensed under the Apache License, Version 2.0 (the "License"); | ||
you may not use this file except in compliance with the License. | ||
You may obtain a copy of the License at | ||
|
||
http://www.apache.org/licenses/LICENSE-2.0 | ||
|
||
Unless required by applicable law or agreed to in writing, software | ||
distributed under the License is distributed on an "AS IS" BASIS, | ||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
See the License for the specific language governing permissions and | ||
limitations under the License. | ||
*/ | ||
|
||
|
||
package v1alpha1 | ||
|
||
import ( | ||
corev1 "k8s.io/api/core/v1" | ||
"k8s.io/apimachinery/pkg/runtime" | ||
metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" | ||
) | ||
|
||
// +genclient | ||
// +k8s:deepcopy-gen:interfaces=k8s.io/apimachinery/pkg/runtime.Object | ||
|
||
// MachineClass can be used to templatize and re-use provider configuration | ||
// across multiple Machines / MachineSets / MachineDeployments. | ||
// +k8s:openapi-gen=true | ||
// +resource:path=machineclasses | ||
type MachineClass struct { | ||
metav1.TypeMeta `json:",inline"` | ||
// +optional | ||
metav1.ObjectMeta `json:"metadata,omitempty"` | ||
|
||
// The total capacity available on this machine type (cpu/memory/disk). | ||
// | ||
// WARNING: It is up to the creator of the MachineClass to ensure that | ||
// this field is consistent with the underlying machine that will | ||
// be provisioned when this class is used, to inform higher level | ||
// automation (e.g. the cluster autoscaler). | ||
Capacity corev1.ResourceList `json:"capacity"` | ||
|
||
// How much capacity is actually allocatable on this machine. | ||
// Must be equal to or less than the capacity, and when less | ||
// indicates the resources reserved for system overhead. | ||
// | ||
// WARNING: It is up to the creator of the MachineClass to ensure that | ||
// this field is consistent with the underlying machine that will | ||
// be provisioned when this class is used, to inform higher level | ||
// automation (e.g. the cluster autoscaler). | ||
Allocatable corev1.ResourceList `json:"allocatable"` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From what I understand, this is the capacity minus the amount that kubelet is going to reserve on the node. I don't think you can know what that reserve is going to be just given a machine class. I know for GKE, we vary the reserve for each release, and possibly by machine size. Perhaps the best way to represent this would be to officially model the Kubelet reserved resources in the MachineSpec (and therefore MachineSet and MachineDeployment). If we did that, we could drop Allocatable here, and autoscalers of deployments could pick the capacity from machine class and subtract reserved from machine spec. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree with @krousey. There is no way to calculate in advance the allocated resources - the Machine class doesn't have a knowledge of which There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The intent is that this would indicate to the cluster autoscaler how much actual capacity would exist once the "node allocatable" overhead was subtracted. The fact that the overhead varies by version makes putting this variable here... difficult, since it would tightly couple a machineclass to a specific k8s version if you wanted to adhere to the warning text. @krousey - Is your suggestion of putting reserved in the machine spec to put it next to the kubelet version, since it is tightly coupled with it? |
||
|
||
// Provider-specific configuration to use during node creation. | ||
ProviderConfig runtime.RawExtension `json:"providerConfig"` | ||
|
||
// TODO: should this use an api.ObjectReference to a 'MachineTemplate' instead? | ||
// A link to the MachineTemplate that will be used to create provider | ||
// specific configuration for Machines of this class. | ||
// MachineTemplate corev1.ObjectReference `json:machineTemplate` | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this needed? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I added this comment as an alternate design -- one thing we'd thought about was splitting this data across two objects (class + template) and the template could potentially be used directly by machine in addition to machine class. Not sure if that's valuable or not though, so I put this here to foster discussion. |
||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't it better to inline or reference the
MachineClass
and notProviderConfig
?Inline:
Reference:
I find that more flexible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think it should be necessary to specify the capacity / allocatable on a single machine if you inline the provider config. I think of the class is a separate way to bring the provider specific data, not something inherent to the spec of the machine.