mirror of
https://github.com/mulgadc/spinifex.git
synced 2026-10-19 19:01:42 +00:00
Josh Siviour
f14fb64562
* feat(eks): unify eks-server + eks-agent into one eks-node AMI Collapse the two K3s AMIs into a single spinifex-eks-node image whose role (server vs agent) is chosen per-instance at first boot, halving build time, storage, and CVE-rotation surface. - scripts/images/eks-node/: superset manifest + merged setup.sh; all role services baked but only crond + the new eks-node-role selector enabled. - eks-node-role first-boot selector reads SPINIFEX_K3S_ROLE, rc-update adds + starts the matching services (server: k3s + eks-token-webhook + k3s-first-boot publisher; agent: k3s-agent), records /etc/spinifex-eks/role, self-disables. Paths are env-overridable; eks-node-role_test.sh covers all five cases. - mulga-eks-etcd-snapshot.sh early-exits on agent nodes. - k3s_server_vm.go seeds SPINIFEX_K3S_ROLE=server into first-boot.env. - Makefile/dev-install: build-eks-node-image / import-eks-node-image replace the server+agent targets. - Delete scripts/images/eks-server + eks-agent. The launcher resolves the AMI by the spinifex:managed-by=eks tag, so running clusters (which hold the resolved AMI ID) are unaffected. AMI bake + cluster boot are operational integration steps, not yet run. * fix(eks): order eks-node-role after cloud-config/cloud-final The first-boot role selector reads /etc/spinifex-eks/first-boot.env, which cloud-init delivers via write_files in the cloud-config/cloud-final stages. The selector only depended on net+cgroups, so on a fast boot it could start before write_files landed and read a missing role env. Add an after-ordering on cloud-config + cloud-final so the env file is always present first.
50 lines
1.9 KiB
Plaintext
Executable File
50 lines
1.9 KiB
Plaintext
Executable File
#!/sbin/openrc-run
|
|
# K3s server control plane. v1 = single-node embedded SQLite (kine) datastore;
|
|
# the per-cluster config.yaml omits cluster-init so k3s uses SQLite, not etcd
|
|
# (etcd's per-commit fsync stalls on the viperblock root volume). Data lives at
|
|
# /var/lib/rancher/k3s; subsequent starts reuse it. Multi-server HA needs etcd
|
|
# and is deferred.
|
|
|
|
description="K3s Kubernetes server (Mulga EKS control plane)"
|
|
command="/usr/local/bin/k3s"
|
|
command_args="server --config /etc/rancher/k3s/config.yaml"
|
|
command_background="yes"
|
|
pidfile="/run/k3s.pid"
|
|
output_log="/var/log/k3s.log"
|
|
error_log="/var/log/k3s.log"
|
|
|
|
# Generous start timeout — K3s bootstraps containerd, initialises the SQLite
|
|
# datastore, pulls system images. First boot can take 2-3 minutes on cold cache.
|
|
start_stop_daemon_args="--wait 5000"
|
|
|
|
depend() {
|
|
need net cgroups
|
|
after firewall
|
|
}
|
|
|
|
start_pre() {
|
|
# config.yaml is written by k3s-first-boot from the skeleton + cloud-init
|
|
# data. Refuse to start if neither exists.
|
|
if [ ! -f /etc/rancher/k3s/config.yaml ]; then
|
|
if [ -f /etc/rancher/k3s/config.yaml.skel ]; then
|
|
cp /etc/rancher/k3s/config.yaml.skel /etc/rancher/k3s/config.yaml
|
|
else
|
|
eerror "no /etc/rancher/k3s/config.yaml and no .skel to derive from"
|
|
return 1
|
|
fi
|
|
fi
|
|
|
|
# The apiserver is configured with --authentication-token-webhook-config-file
|
|
# pointing at the kubeconfig eks-token-webhook writes at startup. `before k3s`
|
|
# orders the webhook's start but it backgrounds, so wait (bounded) for the
|
|
# kubeconfig to land before letting the apiserver load a missing file.
|
|
i=0
|
|
while [ ! -f /etc/spinifex-eks/token-webhook.kubeconfig ] && [ "${i}" -lt 30 ]; do
|
|
sleep 1
|
|
i=$((i + 1))
|
|
done
|
|
if [ ! -f /etc/spinifex-eks/token-webhook.kubeconfig ]; then
|
|
ewarn "eks-token-webhook kubeconfig absent after ${i}s; IAM token auth will be unavailable until the webhook starts"
|
|
fi
|
|
}
|