
This change includes several interconnected features: * Migration to Deckhand-based configuration. This is integrated here, because new configuration data were needed, so it would have been wasted effort to either implement it in the old format or to update the old configuration data to Dechkand format. * Failing faster with stronger validation. Migration to Deckhand configuration was a good opportunity to add schema validation, which is a requirement in the near term anyway. Additionally, rendering all templates up front adds an additional layer of "fail-fast". * Separation of certificate generation and configuration assembly into different commands. Combined with Deckhand substitution, this creates a much clearer distinction between Promenade configuration and deployable secrets. * Migration of components to charts. This is a key step that will enable support for dynamic node management. Additionally, this paves the way for significant configurability in component deployment. * Version of kubelet is configurable & controlled via download url. * Restructuring templates to be more intuitive. Many of the templates require changes or deletion due to the migration to charts. * Installation of pre-configured useful tools on hosts, including calicoctl. * DNS is now provided by coredns, which is highly configurable. Change-Id: I9f2d8da6346f4308be5083a54764ce6035a2e10c
1.3 KiB
1.3 KiB
Kubernetes Node
Configuration for a basic node in the cluster.
Sample Document
Here is a sample document:
schema: promenade/KubernetesNode/v1
metadata:
schema: metadata/Document/v1
name: n1
layeringDefinition:
abstract: false
layer: site
data:
hostname: n1
ip: 192.168.77.11
join_ip: 192.168.77.10
labels:
static:
- node-role.kubernetes.io/master=
dynamic:
- calico-etcd=enabled
- kubernetes-apiserver=enabled
- kubernetes-controller-manager=enabled
- kubernetes-etcd=enabled
- kubernetes-scheduler=enabled
- ucp-control-plane=enabled
Host Information
Essential host-specific information is specified in this document,
including the hostname
, ip
, and
join_ip
.
The join_ip
is used to specify which host should be used
when adding a node to the cluster.
Labels
Kubernetes labels can be specified under the labels
key
in two ways:
- Via the
static
key, which is a list of labels to be applied immediately when thekubelet
process starts. - Via the
dynamic
key, which is a list of labels to be applied after the node is marked as Ready by Kubernetes.