Linkerd is in Digital Ocean Kubernetes’ product page (Use Kubernetes Tooling). However, when I run “linkerd check –pre”, I get:
pre-kubernetes-capability
-------------------------
× has NET_ADMIN capability
found 2 PodSecurityPolicies, but none provide NET_ADMIN
see https://linkerd.io/checks/#pre-k8s-cluster-net-admin for hints
Is it possible to install Linkerd in DO managed Kubernetes?
Hi @csantos,
You should be able to use Linkerd today, our DOKS clusters do have NET_ADMIN capability by default.
What version is the cluster that you created? Are the other checks passing, did you only paste the failure?
I confirmed on 3 of our latest patch versions for 1.12, 1.13, and 1.14. Using https://linkerd.io/2/getting-started/ after spinning up a DOKS cluster I am seeing all pre-checks pass:
$ linkerd check --pre
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create Namespaces
√ can create ClusterRoles
√ can create ClusterRoleBindings
√ can create CustomResourceDefinitions
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create ConfigMaps
pre-kubernetes-capability
-------------------------
√ has NET_ADMIN capability
linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date
Status check results are √
After installing linkerd manifests I’m seeing all checks pass:
$ linkerd check
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
linkerd-existence
-----------------
√ control plane namespace exists
√ controller pod is running
√ can initialize the client
√ can query the control plane API
linkerd-api
-----------
√ control plane pods are ready
√ control plane self-check
√ [kubernetes] control plane can talk to Kubernetes
√ [prometheus] control plane can talk to Prometheus
√ no invalid service profiles
linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date
control-plane-version
---------------------
√ control plane is up-to-date
√ control plane and cli versions match
Status check results are √
I just confirmed on a 1.14.1-do.2 cluster:
$ linkerd check --pre
kubernetes-api
--------------
√ can initialize the client
√ can query the Kubernetes API
kubernetes-version
------------------
√ is running the minimum Kubernetes API version
√ is running the minimum kubectl version
pre-kubernetes-setup
--------------------
√ control plane namespace does not already exist
√ can create Namespaces
√ can create ClusterRoles
√ can create ClusterRoleBindings
√ can create CustomResourceDefinitions
√ can create ServiceAccounts
√ can create Services
√ can create Deployments
√ can create ConfigMaps
pre-kubernetes-capability
-------------------------
√ has NET_ADMIN capability
linkerd-version
---------------
√ can determine the latest version
√ cli is up-to-date
Status check results are √
What’s your cluster UUID? You can grab this from doctl or from the URL in your DO cloud panel.
Ok I see the issue now, thanks for the additional data.
It looks like linkerd check --pre makes this assumption (https://github.com/linkerd/linkerd2/pull/2421):
the presense of PodSecurityPolicies in the cluster means the PodSecurityPolicy admission controller is installed. If the admission controller is not installed, but PSPs exists that restrict
NET_ADMIN, linkerd check will incorrectly report the user does not have that capability.
I’ve been running linkerd check --pre on empty clusters, meaning there are no PodSecurityPolicies in it, but your cluster has a couple PSPs created by grafana. I was able to reproduce what you’re seeing by running on one of my clusters with grafana-created PSPs as well.
The reason this assumption is not valid is that the presence of the PSP CRD does not actually imply that the PSP admission controller is enabled. We do not enable the PSP admissions controller by default in DOKS clusters, as that would restrict deployment of any workloads until an initial PSP is added.
You can see the checks pass by running it on a cluster without any PSPs, or by adding a dummy PSP that allows NET_ADMIN since the linkerd check logic expects this if any PSPs exist. I’d recommend the former.
Rest assured though, you can run linkerd on DOKS :)
Thank you for the awesome support! I installed linkerd and its post-install check was successful.