deduplicate location of kubeconfig #871

Open
opened 2024-07-12 15:55:39 +00:00 by zramsay · 2 comments
Member

In a deployment, the kubeconfig.yml is specified in 2, sometimes 3 locations. For example, dir/spec.yml has the line kube-config: ~/.kube/config-default.yaml but also requires that same file at dir/kubeconfig.yml. In the case of the webapp-deployer, another copy of the file is required at dir/data/config/kube.yml.

In a deployment, the `kubeconfig.yml` is specified in 2, sometimes 3 locations. For example, `dir/spec.yml` has the line `kube-config: ~/.kube/config-default.yaml` but also requires that same file at `dir/kubeconfig.yml`. In the case of the webapp-deployer, another copy of the file is required at `dir/data/config/kube.yml`.
Owner

I think this is ok for now. The spec file is the source for this config data. The file specified in the spec file is copied into the deployment dir on deployment creation to make deployment immutable (otherwise someone could modify or delete the file in its original location later). The spec file is copied into the deployment dir for similar reasons -- it isn't actually used. The webapp deployer is a special case where the app itself communicates with the cluster to do its job, so it has to break the fourth wall to get its credentials.

I think this is ok for now. The spec file is the source for this config data. The file specified in the spec file is copied into the deployment dir on deployment creation to make deployment immutable (otherwise someone could modify or delete the file in its original location later). The spec file is copied into the deployment dir for similar reasons -- it isn't actually used. The webapp deployer is a special case where the app itself communicates with the cluster to do its job, so it has to break the fourth wall to get its credentials.
Owner

Just from an outside perspective my initial thought when deploying to k8s was to define a context to use in SO and have it automatically look for this context in my available ~/.kube/ config files, or take an activated context from something like kubie.

This falls in line more consistently with generic k8s tooling but obviously breaks the immersion of the deployment directory.

Just from an outside perspective my initial thought when deploying to k8s was to define a context to use in SO and have it automatically look for this context in my available ~/.kube/ config files, or take an activated context from something like kubie. This falls in line more consistently with generic k8s tooling but obviously breaks the immersion of the deployment directory.
Sign in to join this conversation.
No Milestone
No project
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: cerc-io/stack-orchestrator#871
No description provided.