You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem or a Pull Request
#1122 - wants to specify the name of a kubeconfig context on creation, which for subsequent creations would be rendered unnecessary ... for initial creation this ticket still applies #323 - wants to update a file with the new kubeconfig, which would be rendered unnecessary if the old one could be re-used
Scope of your request
a new flag for a command (e.g. k3d cluster create --kubeconfig-reuse [FILE:]CONTEXT)?
Describe the solution you'd like
When creating a development cluster with k3d often we will expose the cluster to other users via --api-port=some-non-localhost:some-port and these users have to jump through a hoop of some sort to obtain the kubeconfig.
I suggest that the creation of a new cluster use the context from an existing (or the default) kubeconfig so that the replacement cluster will be accessible using the exact same credentials. This way anyone who was accessing the old incarnation of the cluster will be unaffected when the cluster is re-created.
Devil's Advocate: The old and new clusters are not "the same cluster" so why pretend that they are? Answer: convenience as "the same"-purposed dev cluster may come and go repeatedly as the cluster config is tweaked via recreation instead of via nip/tuck of an existing cluster that might be harder to maintain.
Describe alternatives you've considered
Accept that there will be new kubeconfig credentials whenever "the same" cluster is re-created from scratch and ask users to pull this new config and manage re-merging it with their own kubeconfig each and every time.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem or a Pull Request
#1122 - wants to specify the name of a kubeconfig context on creation, which for subsequent creations would be rendered unnecessary ... for initial creation this ticket still applies
#323 - wants to update a file with the new kubeconfig, which would be rendered unnecessary if the old one could be re-used
Scope of your request
k3d cluster create --kubeconfig-reuse [FILE:]CONTEXT
)?Describe the solution you'd like
When creating a development cluster with k3d often we will expose the cluster to other users via
--api-port=some-non-localhost:some-port
and these users have to jump through a hoop of some sort to obtain the kubeconfig.I suggest that the creation of a new cluster use the context from an existing (or the default) kubeconfig so that the replacement cluster will be accessible using the exact same credentials. This way anyone who was accessing the old incarnation of the cluster will be unaffected when the cluster is re-created.
Devil's Advocate: The old and new clusters are not "the same cluster" so why pretend that they are? Answer: convenience as "the same"-purposed dev cluster may come and go repeatedly as the cluster config is tweaked via recreation instead of via nip/tuck of an existing cluster that might be harder to maintain.
Describe alternatives you've considered
Accept that there will be new kubeconfig credentials whenever "the same" cluster is re-created from scratch and ask users to pull this new config and manage re-merging it with their own kubeconfig each and every time.
The text was updated successfully, but these errors were encountered: