Portainer has a really rich management UI that aims to help Dev and Ops users navigate their way through the various deployment and configuration options for applications on Kubernetes, but what if your Devs and/or Ops staff prefer to use their CLI or a locally installed tool, rather than managing via a web browser.
Well thats easy with Portainer.
Beyond our UI, which includes an integrated KubeCTL shell, Portainer is also a full featured secure KubeAPI proxy. This proxy allows your users to pick and choose the applications they use to manage Kubernetes clusters they have been granted access to.
So how..
First up, we will assume that you have a user created in Portainer (called Bethany), and that she has been granted access to 2x Kubernetes Clusters, Prod and Dev.
When Bethany logs into Portainer she sees the following:
in the Prod Cluster, Bethany can see the default namespace, and a namespace called "webapp"
and in the Webapp namespace, she can see a single deployment, called "nginx"
and in Dev, she can see the default namespace, and a namespace called "webapp-dev"
and the app nginx-dev is running within the namespace.
OK, so how does this all translate to the CLI..
Bethany just needs to click "Home" and then click on "KubeConfig".. Select both of the clusters, then click "Download File", then open the file in notepad..
Now, on Bethany's PC (i will assume Windows here), open c:\users\Bethany\.kube and create a file called config. (or if one is there, you can replace the contents.
Copy the content of the kubeconfig.yaml file from Portainer, and paste it into the config. file. Save and Exit.
So that has configured KubeCTL, so open a command prompt and lets see..
Type "kubectl config get-contexts" and see that both clusters are listed.
the Prod cluster is the default, so lets type "kubectl get namespaces"
Dont worry about seeing the other namespaces, as whilst Bethany can list them, she has no access to them, type "kubeget get pods -n kube-system" to prove this to yourself.
Lets list the deployments in the namespace webapp, "kubectl get deployments -n webapp"
and lets list the pods in the webapp namespace.. "kubectl get pods -n webapp"
all good..
lets scale up that replicaset to 2 instances. "kubectl scale --replicas=2 deployment nginx -n webapp
and check by looking at pods..
and back in Portainer.. refresh the applications page.
Success.. so you just used the CLI to manage a deployment that was initiated in Portainer.
We can now switch contexts and do the same thing for Dev... we wont though, we will just list things, to show..
OK, so how about Lens..
Well, Lens auto-discovers any clusters that exist in your .kube\config file, so just lauch Lens (install it first if you dont already have it).
Click "Browse Clusters in Catalog", then click on the 3 dots, and click "Pin to Hotbar"
Click on one of the clusters in the left bar.. then click "Deployments" and change the namespace from default to webapp.
Note, because this user is a restricted user, Lens will generate a lot of ACL errors if you try to view namespaces for which the user has no access to (or select all namespaces), you can fix that by telling Lens which namespaces you DO actually have access to.
Click the menu in the sidebar, then the cluster, the three dots, then "settings"
Enter the two namespaces, default and webapp then click ESC
Click "disconnect", then "reconnect" to activate the changes.
Now when you navigate, you will only see the namespaces you have access to, and not a screen of errors.
OK, and now lets try a scale from Lens..
Success..
And in Portainer.. the change is seen too..
So there you have it.. you can manage your Kubernetes environments from either KubeCTL or Lens via Portainer.. simple, easy, and centralised..
Give it a go..
COMMENTS