Line references below are against commit 3e5042553f0c5ab4c2a3d8f621c1144c879d25e5 of aether-onramp.
Observed behaviour
The ansible deployment user's ~/.kube/config is populated by deps/k8s/roles/rke2/tasks/install.yml:326-336:
- name: copy /etc/rancher/rke2/rke2.yaml {{ ansible_env.HOME }}/.kube/config
copy:
src: /etc/rancher/rke2/rke2.yaml
dest: "{{ ansible_env.HOME }}/.kube/config"
...Any integration that brings a pre-existing RKE2 / K3s / managed-k8s cluster — and therefore skips onramp's k8s role — never runs those tasks. kubernetes.core.helm and kubernetes.core.k8s* tasks in other roles then fall back to helm's default http://localhost:8080 and fail:
Error: Kubernetes cluster unreachable: Get \"http://localhost:8080/version\": dial tcp 127.0.0.1:8080: connect: connection refused
aether-ops-bootstrap hit this when it replaced onramp's k8s install with its own RKE2 setup; it had to re-implement the kubeconfig copy to get the 5gc playbook working. Any other integrator that brings their own cluster will hit the same wall.
Proposed fix
Extract the current kubeconfig-copy tasks (deps/k8s/roles/rke2/tasks/install.yml:326-336 + the perms that follow) into a small standalone role, e.g. roles/kubeconfig_for_user, that:
- Probes for a valid kubeconfig on disk in a fixed priority order:
/etc/rancher/rke2/rke2.yaml, /etc/rancher/k3s/k3s.yaml, then $KUBECONFIG if set.
- Copies the first match to
{{ ansible_env.HOME }}/.kube/config owned by the deployment user at mode 0600.
- Is idempotent (skip if the destination is already a valid kubeconfig pointing at the same cluster).
Invoke from both the 5gc and k8s playbooks as a pre_tasks: so it runs whether or not onramp's own k8s role is responsible for standing up the cluster. Operators bringing their own cluster just skip the k8s role and still get a working deployment-user kubeconfig.
Context: one of six findings from an airgap integration pass. Especially valuable for integrators replacing the k8s role with a bespoke bootstrap.
Line references below are against commit
3e5042553f0c5ab4c2a3d8f621c1144c879d25e5ofaether-onramp.Observed behaviour
The ansible deployment user's
~/.kube/configis populated bydeps/k8s/roles/rke2/tasks/install.yml:326-336:Any integration that brings a pre-existing RKE2 / K3s / managed-k8s cluster — and therefore skips onramp's k8s role — never runs those tasks.
kubernetes.core.helmandkubernetes.core.k8s*tasks in other roles then fall back to helm's defaulthttp://localhost:8080and fail:aether-ops-bootstraphit this when it replaced onramp's k8s install with its own RKE2 setup; it had to re-implement the kubeconfig copy to get the 5gc playbook working. Any other integrator that brings their own cluster will hit the same wall.Proposed fix
Extract the current kubeconfig-copy tasks (
deps/k8s/roles/rke2/tasks/install.yml:326-336+ the perms that follow) into a small standalone role, e.g.roles/kubeconfig_for_user, that:/etc/rancher/rke2/rke2.yaml,/etc/rancher/k3s/k3s.yaml, then$KUBECONFIGif set.{{ ansible_env.HOME }}/.kube/configowned by the deployment user at mode0600.Invoke from both the 5gc and k8s playbooks as a
pre_tasks:so it runs whether or not onramp's own k8s role is responsible for standing up the cluster. Operators bringing their own cluster just skip the k8s role and still get a working deployment-user kubeconfig.Context: one of six findings from an airgap integration pass. Especially valuable for integrators replacing the k8s role with a bespoke bootstrap.