mirror of
https://github.com/mulgadc/spinifex.git
synced 2026-10-15 17:11:30 +00:00
feat(eks): managed control-plane VPC (Set B) + control-plane lifecycle hardening (#356)
* feat(eks): VM-side managed-addon delivery transport
Stage CreateAddon manifests in KV host-side; the control-plane VM pulls the
staged set through the AWS gateway (signed GET /clusters/{name}/internal-addons/
{accountId}), renders the baked bundles into the K3s auto-deploy dir, and
reports per-addon delivery status on a dedicated eks.addon.*.status channel that
the cluster reconciler CASes onto AWS-visible AddonStatus (CREATING->ACTIVE).
- gateway: ListInternalAddons route + ListStagedAddonManifests NATS action
- handlers: addon status reconciler (nextAddonStatus), staging installer
- eks-node AMI: eks-gateway-fetch binary + mulga-eks-addon-sync agent
- agent renders idempotently (cmp before replace) so K3s auto-deploy does not
re-apply every tick and clear the Addon CR .status.gvks readiness signal
- agent mirrors per-tick delivery outcomes to the serial console for host-side
observability
* fix(eks): provision cluster NLB synchronously so the endpoint carries the real front-end IP
The cluster NLB front-end IP is assigned by the async LB-VM launch
(launchLBVMAsync), but EnsureClusterNLB read it back synchronously right after
CreateLoadBalancer returned — losing the race and falling back to the synthetic
<lb>.elb.spinifex.local DNS name. That name is unresolvable (no Route53) and is
not in the apiserver serving-cert SAN, so kubectl against the cluster never
connects.
Split the elbv2 create: the public CreateLoadBalancer stays async (267.4 — an
inline multi-minute VM boot head-of-line-blocks the gateway responder), and a
new CreateLoadBalancerSync drives the data-plane launch inline and returns the
LB carrying its front-end address. The EKS cluster-create worker runs off the
gateway responder, so it uses the sync entry and reads the IP from the return
value instead of racing persisted state. No polling.
- elbv2: factor provisionLBDataPlane out of launchLBVMAsync; add CreateLoadBalancerSync
- eks: ensureClusterLB uses the sync entry, sets FrontendIP from the result,
drops the read-back; EnsureClusterNLB fails loud (ErrClusterNLBFrontendIPUnavailable)
when no front-end IP is allocated rather than shipping the DNS-name fallback
- eks: drop the DNS-name endpoint fallback; the endpoint is always the front-end IP
* feat: auto-wire IGW for internet-facing EKS cluster endpoint
An internet-facing cluster NLB allocates an external front-end IP and the
OVN dnat_and_snat for it, but the external switch + localnet + gateway LRP
that make that IP answerable on the wire are built only on IGW attach. The
control-plane NLB is a system instance, so ensure an IGW on cluster build
and reclaim it on teardown.
EnsureClusterIGW (idempotent, reuses a customer IGW untouched) runs before
EnsureClusterNLB when the endpoint is public; DeleteClusterIGW (ownership-
scoped) removes only the cluster-owned IGW in purgeClusterInfra, before the
VPC delete. New IGW dep wired from the daemon.
* fix(eks): tear down infra on failed cluster launch to stop LB EIP leak
A CreateCluster that fails during its background launch flipped the meta
to FAILED but performed no teardown, relying on a later same-name create
to reclaim and purge the infra. EKS cluster names are unique per create,
so that reclaim never fires: the internet-facing load-balancer VM keeps
running with its allocated+associated dnat_and_snat EIP indefinitely.
Over repeated create/delete cycles the EIP pool fills with allocations
bound to terminated instances, so a later allocation's advertised
endpoint and its live OVN NAT diverge onto different pool addresses.
- failClusterLaunch now runs a best-effort purgeClusterInfra on the
in-memory meta (freshest refs even when the failing step was the meta
write itself) before MarkClusterFailed. purgeClusterInfra is
idempotent, so a later reclaim or DeleteCluster re-purge is a no-op;
the FAILED meta is retained for observability.
- Daemon releaseSystemInstanceEIP extracted and called from both
TerminateSystemInstance and cleanupFailedSystemInstance, so a launch
that fails after AssociateAddress releases the eipService allocation
instead of leaking it (MarkFailed's ReleasePublicIP only knows the
externalIPAM path).
* feat: EKS managed control-plane VPC (AWS Set B) composed from EC2 APIs
CreateCluster now auto-builds the managed control-plane VPC under the
system account, the spinifex analogue of AWS EKS's hidden managed-account
VPC: a public subnet for the internet-facing NLB, private subnet(s) for the
k3s control-plane VM(s), and a NAT gateway giving the private CP egress for
image pulls. It is composed from the real EC2 VPC-family APIs
(CreateVpc/Subnet, IGW, RouteTable/Route, NatGateway), so per-subnet egress
gating is wired by the existing topology subscribers off the route-table
events those APIs publish — no direct OVN mutation.
This resolves the mulga-siv-292 root cause: the internet-facing NLB and the
private CP were crammed into one customer subnet with no IGW route, so both
were treated as private and dropped by the lr_in_policy 1100 rule, killing
the LB-VM return leg and lb-agent heartbeat. The CP only survived via a
per-instance 1200 reroute bandaid, now removed — the topology expresses
egress instead.
Placement is uniform single/multi-node (CP always in the private subnet).
The system LB VM heartbeats over the mgmt bridge (SystemGatewayURL) rather
than the WAN. Managed-VPC teardown reclaims NAT GW + EIP, route tables,
subnets, IGW, and the VPC in dependency order. Customer subnetIds (Set A /
worker side) remain consumed-not-created and are deferred to the worker
round.
* fix(eks): bake cluster-owner account into CP-VM EKS_ACCOUNT_ID
The managed control-plane VPC (Set B) launches the K3s control-plane VMs and
their ENIs under the system (infra) account, but the on-VM agents — bootstrap
publish, state report, token-review, and add-on fetch — must key on the
cluster-OWNER (customer) account that owns the cluster meta, namespaces, and
AccessEntry KV. Add ClusterAccountID to K3sServerInput and bake it into the
VM's EKS_ACCOUNT_ID, decoupling it from the infra AccountID the VM launches
under. Without this the VM reported state and fetched add-ons against the
system account, so the cluster never observed a healthy control plane (stuck
CREATING, null CA) and kubectl/add-on delivery timed out.
Also refresh the e2e suite doc comment to describe the Set B topology and the
data-plane subtests (kubectl + managed-addon delivery) that now run.
* fix(eks): explicitly delete addon objects on unstage
K3s does not delete the applied resources when an auto-deploy manifest file is
removed from the server manifests dir (documented behaviour). The addon-sync
GC pass relied on that, so after DeleteAddon the rendered manifest was dropped
but its Namespace/ConfigMap stayed standing — the e2e AddonDelivery GC wait
timed out. Copy the manifest aside, drop the original so K3s stops tracking it,
then kubectl delete the objects (--wait=false to avoid finalizer stalls).
This commit is contained in:
Josh Siviour
@@ -0,0 +1,20 @@
|
||||
# spinifex-noop — managed-addon delivery-transport fixture. Two trivial,
|
||||
# dependency-free objects the addon e2e asserts on to prove the stage → fetch →
|
||||
# render → auto-deploy → ACTIVE → delete round-trip end-to-end, independent of
|
||||
# the CSI or load-balancer-controller bundles. Not a real workload.
|
||||
apiVersion: v1
|
||||
kind: Namespace
|
||||
metadata:
|
||||
name: spinifex-noop
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: spinifex-addon
|
||||
---
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: spinifex-noop
|
||||
namespace: spinifex-noop
|
||||
labels:
|
||||
app.kubernetes.io/managed-by: spinifex-addon
|
||||
data:
|
||||
marker: "spinifex-noop addon delivered"
|
||||
@@ -55,10 +55,16 @@ case "${ROLE}" in
|
||||
rc-update add k3s default
|
||||
rc-update add k3s-first-boot default
|
||||
rc-update add mulga-eks-state-report default
|
||||
# Managed-addon delivery runs only on the primary server: it renders
|
||||
# staged addon bundles into the K3s auto-deploy dir, which a single
|
||||
# writer owns. HA multi-server addon delivery is tracked separately
|
||||
# (mulga-siv-231.7); server-join nodes do not run it.
|
||||
rc-update add mulga-eks-addon-sync default
|
||||
rc-service eks-token-webhook start
|
||||
rc-service k3s start
|
||||
rc-service k3s-first-boot start
|
||||
rc-service mulga-eks-state-report start
|
||||
rc-service mulga-eks-addon-sync start
|
||||
;;
|
||||
server-join)
|
||||
log "configuring server-join role"
|
||||
|
||||
@@ -18,9 +18,9 @@ APK_PACKAGES="ca-certificates curl jq iptables ip6tables conntrack-tools cgroup-
|
||||
# eks-gateway-publish relays the bootstrap envelopes + state reports to the AWS
|
||||
# gateway over SigV4 HTTPS (server role only). The k3s binary is downloaded +
|
||||
# SHA256-verified by setup.sh (network in chroot).
|
||||
BUILD_COMMANDS="CGO_ENABLED=0 GOFIPS140=v1.0.0 go build -o bin/eks-token-webhook ./cmd/eks-token-webhook && CGO_ENABLED=0 GOFIPS140=v1.0.0 go build -o bin/eks-gateway-publish ./cmd/eks-gateway-publish"
|
||||
BUILD_COMMANDS="CGO_ENABLED=0 GOFIPS140=v1.0.0 go build -o bin/eks-token-webhook ./cmd/eks-token-webhook && CGO_ENABLED=0 GOFIPS140=v1.0.0 go build -o bin/eks-gateway-publish ./cmd/eks-gateway-publish && CGO_ENABLED=0 GOFIPS140=v1.0.0 go build -o bin/eks-gateway-fetch ./cmd/eks-gateway-fetch"
|
||||
|
||||
INSTALL_BINARIES="bin/eks-token-webhook:/usr/local/bin/eks-token-webhook bin/eks-gateway-publish:/usr/local/bin/eks-gateway-publish"
|
||||
INSTALL_BINARIES="bin/eks-token-webhook:/usr/local/bin/eks-token-webhook bin/eks-gateway-publish:/usr/local/bin/eks-gateway-publish bin/eks-gateway-fetch:/usr/local/bin/eks-gateway-fetch"
|
||||
|
||||
# All role services ship; none but the selector are enabled at bake time.
|
||||
# eks-node-role picks server vs agent at first boot and enables the rest.
|
||||
@@ -34,6 +34,9 @@ scripts/images/eks-node/k3s-first-boot.initd:/etc/init.d/k3s-first-boot \
|
||||
scripts/images/eks-node/k3s-first-boot.sh:/usr/local/sbin/k3s-first-boot \
|
||||
scripts/images/eks-node/mulga-eks-state-report.initd:/etc/init.d/mulga-eks-state-report \
|
||||
scripts/images/eks-node/mulga-eks-state-report.sh:/usr/local/sbin/mulga-eks-state-report \
|
||||
scripts/images/eks-node/mulga-eks-addon-sync.initd:/etc/init.d/mulga-eks-addon-sync \
|
||||
scripts/images/eks-node/mulga-eks-addon-sync.sh:/usr/local/sbin/mulga-eks-addon-sync \
|
||||
scripts/images/eks-node/addons/spinifex-noop/0.1.0/noop.yaml:/usr/share/spinifex-eks/addons/spinifex-noop/0.1.0/noop.yaml \
|
||||
scripts/images/eks-node/mulga-eks-etcd-snapshot.sh:/etc/periodic/daily/mulga-eks-etcd-snapshot"
|
||||
|
||||
# Only crond (etcd snapshot) + the role selector at bake. The selector adds the
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
#!/sbin/openrc-run
|
||||
# mulga-eks-addon-sync — server-role service that renders Spinifex managed-addon
|
||||
# bundles into the K3s auto-deploy dir and reports per-addon delivery status to
|
||||
# the spinifex control plane every ADDON_SYNC_INTERVAL seconds. The host-side
|
||||
# daemon stages each addon in KV; the VM pulls the staged set through the AWS
|
||||
# gateway (it cannot read NATS/KV directly) and renders the baked bundles.
|
||||
# Enabled on the primary server role by eks-node-role.sh.
|
||||
|
||||
description="Mulga EKS managed-addon delivery agent"
|
||||
command="/usr/local/sbin/mulga-eks-addon-sync"
|
||||
command_background="yes"
|
||||
pidfile="/run/mulga-eks-addon-sync.pid"
|
||||
output_log="/var/log/mulga-eks-addon-sync.log"
|
||||
error_log="/var/log/mulga-eks-addon-sync.log"
|
||||
|
||||
# Cadence the sync loop sleeps between pulls. 30s keeps CreateAddon→ACTIVE
|
||||
# latency low without hammering the gateway.
|
||||
export ADDON_SYNC_INTERVAL="${ADDON_SYNC_INTERVAL:-30}"
|
||||
|
||||
depend() {
|
||||
need net
|
||||
after k3s
|
||||
}
|
||||
|
||||
start_pre() {
|
||||
if [ ! -f /etc/spinifex-eks/first-boot.env ]; then
|
||||
eerror "/etc/spinifex-eks/first-boot.env not present — cloud-init did not seed gateway creds"
|
||||
return 1
|
||||
fi
|
||||
}
|
||||
@@ -0,0 +1,199 @@
|
||||
#!/bin/sh
|
||||
set -eu
|
||||
|
||||
# mulga-eks-addon-sync — renders Spinifex managed-addon bundles into the K3s
|
||||
# auto-deploy dir and reports per-addon delivery status back to the spinifex
|
||||
# control plane. The host-side daemon stages each CreateAddon as a manifest
|
||||
# descriptor in KV; the VM cannot read KV directly, so this agent pulls the
|
||||
# staged set through the AWS gateway (eks-gateway-fetch, SigV4) and renders the
|
||||
# baked bundle for each one. Status flows back via eks-gateway-publish on the
|
||||
# "addon" channel, where the reconciler CASes the AddonRecord CREATING→ACTIVE.
|
||||
#
|
||||
# Pull (host→VM): GET /clusters/{cluster}/internal-addons/{accountId}
|
||||
# Report (VM→host): eks.addon.{accountID}.{clusterName}.status
|
||||
#
|
||||
# Runs server-role only (it owns the single auto-deploy dir); enabled by
|
||||
# eks-node-role.sh. Loops every ADDON_SYNC_INTERVAL seconds in service mode,
|
||||
# one-shot otherwise.
|
||||
|
||||
ENVFILE=/etc/spinifex-eks/first-boot.env
|
||||
[ -f "${ENVFILE}" ] || { logger -t mulga-eks-addon-sync "${ENVFILE} missing — exiting"; exit 0; }
|
||||
# set -a so the sourced creds are exported to the eks-gateway-{fetch,publish}
|
||||
# children, which read EKS_ACCOUNT_ID etc. from their environment.
|
||||
set -a
|
||||
# shellcheck disable=SC1090
|
||||
. "${ENVFILE}"
|
||||
set +a
|
||||
|
||||
: "${EKS_GATEWAY_URL:?}"
|
||||
: "${EKS_ACCESS_KEY:?}"
|
||||
: "${EKS_SECRET_KEY:?}"
|
||||
: "${EKS_ACCOUNT_ID:?}"
|
||||
: "${EKS_CLUSTER_NAME:?}"
|
||||
|
||||
KUBECONFIG=${KUBECONFIG:-/etc/rancher/k3s/k3s.yaml}
|
||||
export KUBECONFIG
|
||||
|
||||
# Baked bundles live at BAKED_DIR/<addon>/<version>/*.yaml (air-gapped, shipped
|
||||
# in the AMI). Rendered output lands in the K3s auto-deploy dir under a stable
|
||||
# per-addon filename so GC can find orphans this agent owns.
|
||||
BAKED_DIR=/usr/share/spinifex-eks/addons
|
||||
DEPLOY_DIR=/var/lib/rancher/k3s/server/manifests
|
||||
RENDER_PREFIX=spinifex-addon-
|
||||
|
||||
# log mirrors to syslog (on-VM /var/log) and, best-effort, to the serial
|
||||
# console — the host captures ttyS0 to a per-instance log, so this is the only
|
||||
# delivery diagnostics channel reachable from the host (the VM has no
|
||||
# host-routable address). Keep messages terse; one line per sync outcome.
|
||||
log() {
|
||||
logger -t mulga-eks-addon-sync "$*"
|
||||
echo "[mulga-eks-addon-sync] $*" > /dev/console 2>/dev/null || true
|
||||
}
|
||||
|
||||
# report PHASE ADDON VERSION [MESSAGE] — publish one addon status report.
|
||||
report() {
|
||||
_phase=$1; _addon=$2; _version=$3; _msg=${4:-}
|
||||
printf '{"addon":"%s","version":"%s","phase":"%s","message":"%s","ts":%s}' \
|
||||
"${_addon}" "${_version}" "${_phase}" "${_msg}" "$(date +%s)" \
|
||||
| eks-gateway-publish -channel addon 2>&1 | logger -t mulga-eks-addon-sync || true
|
||||
}
|
||||
|
||||
# render_addon ADDON VERSION ROLE_ARN — render the baked bundle into the
|
||||
# auto-deploy dir, substituting the IRSA role ARN. Returns non-zero (and reports
|
||||
# failed) when the baked bundle for ADDON/VERSION is absent.
|
||||
render_addon() {
|
||||
_addon=$1; _version=$2; _role=$3
|
||||
_src="${BAKED_DIR}/${_addon}/${_version}"
|
||||
_dst="${DEPLOY_DIR}/${RENDER_PREFIX}${_addon}.yaml"
|
||||
|
||||
if [ ! -d "${_src}" ]; then
|
||||
log "no baked bundle for ${_addon}/${_version} (looked in ${_src})"
|
||||
report failed "${_addon}" "${_version}" "no baked bundle for version ${_version}"
|
||||
return 1
|
||||
fi
|
||||
|
||||
_tmp="${_dst}.tmp.$$"
|
||||
: > "${_tmp}"
|
||||
for _f in "${_src}"/*.yaml; do
|
||||
[ -e "${_f}" ] || continue
|
||||
sed -e "s|{{SERVICE_ACCOUNT_ROLE_ARN}}|${_role}|g" "${_f}" >> "${_tmp}"
|
||||
printf '\n---\n' >> "${_tmp}"
|
||||
done
|
||||
# Idempotent: only replace the auto-deploy file when the rendered content
|
||||
# actually changed. An unconditional mv bumps the file mtime every tick,
|
||||
# which K3s' auto-deploy controller treats as a change and re-applies —
|
||||
# clearing the Addon CR's .status.gvks each time, so the same-tick readiness
|
||||
# check never observes a settled apply and the add-on stays CREATING forever.
|
||||
if [ -e "${_dst}" ] && cmp -s "${_tmp}" "${_dst}"; then
|
||||
rm -f "${_tmp}"
|
||||
return 0
|
||||
fi
|
||||
mv -f "${_tmp}" "${_dst}"
|
||||
return 0
|
||||
}
|
||||
|
||||
# addon_gvks ADDON — echoes the GVKs K3s' auto-deploy controller applied for the
|
||||
# rendered manifest, empty until it has applied the objects. A non-empty value
|
||||
# means delivery succeeded. Addon-agnostic — confirms delivery, not deep per-pod
|
||||
# health (a later hardening item).
|
||||
#
|
||||
# K3s (v1.32.x) records the applied GVKs in the addon.k3s.cattle.io/gvks
|
||||
# *annotation* (e.g. "/v1, Kind=Namespace;/v1, Kind=ConfigMap"); the Addon CR
|
||||
# carries no .status subresource. The CR is matched by .spec.source (the
|
||||
# absolute path of the rendered file) rather than a guessed CR name, since K3s
|
||||
# derives the name from the path with its own transform.
|
||||
addon_gvks() {
|
||||
_want="${DEPLOY_DIR}/${RENDER_PREFIX}$1.yaml"
|
||||
kubectl -n kube-system get addon -o json 2>/dev/null \
|
||||
| jq -r --arg src "${_want}" \
|
||||
'.items[] | select(.spec.source==$src)
|
||||
| .metadata.annotations["addon.k3s.cattle.io/gvks"] // ""' 2>/dev/null \
|
||||
| grep -v '^$' | head -1 || true
|
||||
}
|
||||
|
||||
# diag_addon ADDON — one-shot console dump of the live K3s state for a stuck
|
||||
# add-on, so a delivery that never reaches ready is diagnosable from the
|
||||
# host-captured serial console (the VM is otherwise unreachable). Fires once per
|
||||
# process via a sentinel to avoid spamming every tick.
|
||||
diag_addon() {
|
||||
[ -f /tmp/.addon-diag-"$1" ] && return 0
|
||||
: > /tmp/.addon-diag-"$1"
|
||||
{
|
||||
echo "----- addon-diag ${1} -----"
|
||||
echo "[deploy dir]"; ls -l "${DEPLOY_DIR}" 2>&1
|
||||
echo "[rendered file head]"; head -40 "${DEPLOY_DIR}/${RENDER_PREFIX}${1}.yaml" 2>&1
|
||||
echo "[all addon CRs]"; kubectl get addon -A 2>&1
|
||||
echo "[addon CR ${RENDER_PREFIX}${1} -o yaml]"; kubectl -n kube-system get addon "${RENDER_PREFIX}${1}" -o yaml 2>&1
|
||||
echo "[namespace ${1}]"; kubectl get ns "${1}" 2>&1
|
||||
echo "[configmaps in ${1}]"; kubectl -n "${1}" get cm 2>&1
|
||||
echo "----- end addon-diag ${1} -----"
|
||||
} > /dev/console 2>&1 || true
|
||||
}
|
||||
|
||||
sync_once() {
|
||||
_staged=$(mktemp)
|
||||
_ferr=$(mktemp)
|
||||
if ! eks-gateway-fetch -resource addons > "${_staged}" 2>"${_ferr}"; then
|
||||
log "fetch staged addons failed — keeping current state: $(tr '\n' ' ' < "${_ferr}")"
|
||||
rm -f "${_staged}" "${_ferr}"
|
||||
return 0
|
||||
fi
|
||||
rm -f "${_ferr}"
|
||||
|
||||
# Names currently staged, for the GC pass below.
|
||||
_names=$(cut -f1 "${_staged}")
|
||||
_count=$(grep -c . "${_staged}" 2>/dev/null || echo 0)
|
||||
log "fetch ok: ${_count} staged addon(s)"
|
||||
|
||||
# Render/refresh each staged addon and report its phase.
|
||||
while IFS=$(printf '\t') read -r _addon _version _role _cfg_b64; do
|
||||
[ -n "${_addon}" ] || continue
|
||||
: "${_cfg_b64:-}" # config values reserved for per-addon templating (follow-up)
|
||||
if render_addon "${_addon}" "${_version}" "${_role}"; then
|
||||
_gvks=$(addon_gvks "${_addon}")
|
||||
if [ -n "${_gvks}" ]; then
|
||||
log "addon ${_addon}/${_version}: applied + ready (gvks=${_gvks})"
|
||||
report ready "${_addon}" "${_version}"
|
||||
else
|
||||
log "addon ${_addon}/${_version}: applied, not ready yet (no K3s Addon CR for ${RENDER_PREFIX}${_addon}.yaml with populated .status.gvks)"
|
||||
diag_addon "${_addon}"
|
||||
report applied "${_addon}" "${_version}"
|
||||
fi
|
||||
fi
|
||||
done < "${_staged}"
|
||||
rm -f "${_staged}"
|
||||
|
||||
# GC: remove rendered manifests this agent owns whose addon is no longer
|
||||
# staged (DeleteAddon removed its descriptor). K3s does NOT delete the applied
|
||||
# objects when the manifest file disappears, so delete them explicitly.
|
||||
for _file in "${DEPLOY_DIR}/${RENDER_PREFIX}"*.yaml; do
|
||||
[ -e "${_file}" ] || continue
|
||||
_base=$(basename "${_file}")
|
||||
_name=${_base#"${RENDER_PREFIX}"}
|
||||
_name=${_name%.yaml}
|
||||
if ! printf '%s\n' "${_names}" | grep -qx "${_name}"; then
|
||||
log "unstaging addon ${_name} (no longer staged)"
|
||||
# Copy the manifest aside, drop the original so K3s stops tracking it
|
||||
# (and never re-applies), then delete the objects it rendered.
|
||||
# --wait=false so namespace finalizers don't stall the sync loop.
|
||||
_gc=$(mktemp)
|
||||
cp "${_file}" "${_gc}"
|
||||
rm -f "${_file}"
|
||||
kubectl delete -f "${_gc}" --ignore-not-found --wait=false 2>&1 \
|
||||
| logger -t mulga-eks-addon-sync || true
|
||||
rm -f "${_gc}"
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
mkdir -p "${DEPLOY_DIR}"
|
||||
|
||||
if [ -n "${ADDON_SYNC_INTERVAL:-}" ] && [ "${ADDON_SYNC_INTERVAL}" -gt 0 ] 2>/dev/null; then
|
||||
log "starting: cluster=${EKS_CLUSTER_NAME} account=${EKS_ACCOUNT_ID} interval=${ADDON_SYNC_INTERVAL}s gateway=${EKS_GATEWAY_URL}"
|
||||
while true; do
|
||||
sync_once
|
||||
sleep "${ADDON_SYNC_INTERVAL}"
|
||||
done
|
||||
else
|
||||
sync_once
|
||||
fi
|
||||
@@ -43,9 +43,10 @@ ln -sf /usr/local/bin/k3s /usr/local/bin/ctr
|
||||
# Init scripts ship as 0644 from INSTALL_FILES; OpenRC requires 0755. Every
|
||||
# role's services are baked; the selector enables the right ones at first boot.
|
||||
chmod 0755 /etc/init.d/eks-node-role /etc/init.d/k3s /etc/init.d/k3s-agent \
|
||||
/etc/init.d/eks-token-webhook /etc/init.d/k3s-first-boot /etc/init.d/mulga-eks-state-report
|
||||
/etc/init.d/eks-token-webhook /etc/init.d/k3s-first-boot /etc/init.d/mulga-eks-state-report \
|
||||
/etc/init.d/mulga-eks-addon-sync
|
||||
chmod 0755 /usr/local/sbin/eks-node-role /usr/local/sbin/k3s-first-boot \
|
||||
/usr/local/sbin/mulga-eks-state-report
|
||||
/usr/local/sbin/mulga-eks-state-report /usr/local/sbin/mulga-eks-addon-sync
|
||||
chmod 0755 /etc/periodic/daily/mulga-eks-etcd-snapshot
|
||||
|
||||
# K3s server config — skeleton; cloud-init / first-boot fills in the
|
||||
|
||||
Reference in New Issue
Block a user