c057695a3f
* Upstream systemd issue: github.com/systemd/systemd/issues/1312 * Units which fail due to unmet dependencies are not restarted as they would be upon failure. Kubelet should keep trying until flanneld is active. * Apply the recommended work-around by adding an ExecStart which checks for a Wanted dependency and purposefully fails when unmet in order to force a restart to keep trying.
Examples
These examples network boot and provision machines into CoreOS clusters using bootcfg. You can re-use their profiles to provision your own physical machines.
| Name | Description | CoreOS Version | FS | Docs |
|---|---|---|---|---|
| pxe | CoreOS via iPXE | alpha/1053.2.0 | RAM | reference |
| grub | CoreOS via GRUB2 Netboot | alpha/1053.2.0 | RAM | NA |
| pxe-disk | CoreOS via iPXE, with a root filesystem | alpha/1053.2.0 | Disk | reference |
| etcd, etcd-docker | iPXE boot a 3 node etcd cluster and proxy | alpha/1053.2.0 | RAM | reference |
| etcd-install | Install a 3-node etcd cluster to disk | alpha/1053.2.0 | Disk | reference |
| k8s, k8s-docker | Kubernetes cluster with 1 master and 2 workers, TLS-authentication | alpha/1053.2.0 | Disk | tutorial |
| k8s-install | Install a Kubernetes cluster to disk (1 master) | alpha/1053.2.0 | Disk | tutorial |
| bootkube | iPXE boot a self-hosted Kubernetes cluster (with bootkube) | alpha/1053.2.0 | Disk | tutorial |
| bootkube-install | Install a self-hosted Kubernetes cluster (with bootkube) | alpha/1053.2.0 | Disk | tutorial |
| torus | CoreOS Torus distributed storage | alpha/1053.2.0 | Disk | tutorial |
Tutorials
Get started running bootcfg on your Linux machine to network boot and provision clusters of VMs or physical hardware.
- bootcfg with rkt
- bootcfg with Docker
- Static Kubernetes v1.2.4
- Self-hosted Kubernetes v1.3.0-beta.2
- Torus Storage
Experimental
These examples demonstrate booting and provisioning various (often experimental) CoreOS clusters. They have NOT been hardened for production yet. You should write or adapt Ignition configs to suit your needs and hardware.
SSH Keys
Most examples allow ssh_authorized_keys to be added for the core user as machine group metadata.
# /var/lib/bootcfg/groups/default.json
{
"name": "Example Machine Group",
"profile": "pxe",
"metadata": {
"ssh_authorized_keys": ["ssh-rsa pub-key-goes-here"]
}
}
Conditional Variables
"pxe"
Some examples check the pxe variable to determine whether to create a /dev/sda1 filesystem and partition for PXEing with root=/dev/sda1 ("pxe":"true") or to write files to the existing filesystem on /dev/disk/by-label/ROOT ("pxe":"false").
"skip_networkd"
Some examples (mainly Kubernetes examples) check the skip_networkd variable to determine whether to skip configuring networkd. When true, the default networkd config is used, which uses DCHP to setup networking. Use this if you've pre-configured static IP mappings for Kubernetes nodes in your DHCP server. Otherwise, networkd_address, networkd_dns, and networkd_gateway machine metadata are used to populate a networkd configuration on each host.