kubectl-karmada init failing with error

naqvis commented 10 months ago

What happened:

kubectl-karmada when invoking init is failing with error error: failed to create directory: /etc/karmada, error: mkdir /etc/karmada: permission denied

What you expected to happen: init command should successfully install Karmada control plane

How to reproduce it (as minimally and precisely as possible):

Install single node k3s cluster
Install kubectl-karmada
Run kubectl karmada init

Anything else we need to know?:

Environment:

kubectl-karmada or karmadactl version (the result of kubectl-karmada version or karmadactl version):

kubectl karmada version: version.Info{GitVersion:"v1.6.0", GitCommit:"6eb79b38949e480cf7a2e12cfa56fef47bda81ea", GitTreeState:"clean", BuildDate:"2023-05-31T09:55:31Z", GoVersion:"go1.20.4", Compiler:"gc", Platform:"linux/amd64"}

whitewindmills commented 10 months ago

I'm curious if you are logged in as root.

RainbowMango commented 10 months ago

kubectl-karmada when invoking init is failing with error error: failed to create directory: /etc/karmada, error: mkdir /etc/karmada: permission denied

The output shows that you don't have permission to create a directory at /etc/karmada. You might need to talk to your administrator to grant permission to you.

Another approach might be change the default path: The init command default to put the cert and crds file under /etc/karmada directory:

    -d, --karmada-data='/etc/karmada':
    Karmada data path. kubeconfig cert and crds files
    --karmada-pki='/etc/karmada/pki':
    Karmada pki path. Karmada cert files

You can customize a directory that you have permission to access. like :

karmadactl init --karmada-data=~/karmada --karmada-pki=~/karmada   <other flags>

RainbowMango commented 10 months ago

It doesn't seem like a bug. /remove-kind bug /kind question

Please let us know if you have further questions.

naqvis commented 10 months ago

I'm curious if you are logged in as root.

No, I'm not logged in as root.

It doesn't seem like a bug.

I would argue against it. There is no clear indication in documentation or somewhere else that init requires root privileges and for non root users what options are available.

Similarly non-root users can install the Karmada control plane using Helm chart

RainbowMango commented 10 months ago

Thanks for your suggestion. I'll invite init author here to comment. @lonelyCZ

I'm quite sure about does init really requires root permission?

lonelyCZ commented 10 months ago

I'm quite sure about does init really requires root permission?

I think it should not need the root permission. It only need the permission of kubeconfig, as for /etc/karmada directory is only a common dir like /etc/kubernetes, so it can be configured.

There is no clear indication in documentation or somewhere else that init requires root privileges and for non root users what options are available.

It makes sense, perhaps we can note this in the document. We deafult use /etc/karmada that seems more friendly for new Karmada user, especially unify the description of documents, how do you think?

naqvis commented 10 months ago

Thanks @RainbowMango and @lonelyCZ.

Similar to kubectl configurations under user home folder ~/.kube it make sense to use the similar approach (as default) for Karmada artifacts. As requiring a normal user activity to have root privileges should be something which should be avoided for security concerns.

I'm not suggesting that artifacts should be stored under ~/.kube folder, but suggestion is to store operation artifacts under user home folder (as that' the common place, where linux user has full privileges).

My two cents.

RainbowMango commented 10 months ago

We deafult use /etc/karmada that seems more friendly for new Karmada user, especially unify the description of documents, how do you think?

+1

but suggestion is to store operation artifacts under user home folder (as that' the common place, where linux user has full privileges)

The kubectl configuration is normally used by a specific user, so it makes sense to store the configurations in the home folder.

But Karmada configurations(or, Kubernetes configurations), might be used by more than one user. So, I don't think such kind of configuration should be put in a user-specific directory. Take kubeadm as an example, an administrator(probably root) might install Kubernetes, which might be used by more than one user, so the configuration definitely can't be at /root/xxx.

naqvis commented 10 months ago

ake kubeadm as an example, an administrator(probably root) might install Kubernetes, which might be used by more than one user, so the configuration definitely can't be at /root/xxx.

Understand and agree for such use cases, but keep in view that Karmada control plane can be installed via Helm and that doesn't require escalated privileges.

Request here is to please

Update the documentation accordingly stating that init command with default settings (requires escalated privileges & why)
describe the difference between installation via karmadactl init command and helm install, if these two achieves the same result of installing the control plane? or there are some differences? if so what are them?

Thanks again for all of the great work and contributions you are making to the community.

RainbowMango commented 10 months ago

The difference between karmadactl init and helm install is that:

karmadactl init needs a path to store public configurations for multiple users.
helm install doesn't need to store public configurations, it essentially deploys workloads(karmada components) to a specific cluster.

I don't know why we need to document the difference. In addition, we just introduced another installation approach, Karmada Operator, do you mean we also need to note the differences?

Update the documentation accordingly stating that init command with default settings (requires escalated privileges & why)

Sounds good to me. Would you like to send a PR for this?

naqvis commented 10 months ago

Sounds good to me. Would you like to send a PR for this?

Yeah sure, would be happy to do that.

RainbowMango commented 10 months ago

/assign In favor of https://github.com/karmada-io/website/pull/364. Thanks. /remove-kind question /kind cleanup /kind documentation

RainbowMango commented 10 months ago

Sorry, just mistakenly assigned it to me. /unassign /assign @naqvis

RainbowMango commented 10 months ago

I guess we can close it now. /close

karmada-bot commented 10 months ago

@RainbowMango: Closing this issue.

In response to [this](https://github.com/karmada-io/karmada/issues/3619#issuecomment-1575320188): >I guess we can close it now. >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

karmada-io / karmada

kubectl-karmada init failing with error #3619