Outline
For the demos in this section, I installed Kubernetes using the snap package, microk8s. microk8s runs Kubernetes in a sandboxed container environment of its own. For that reason, all my kubectl and helm commands will need to be prefaced by the word microk8s.
We'll begin with kubectl config view. This'll give us a birds-eye-view of our Kubernetes installation environment.
A context is a way to organize project resources on the user-side. This default configuration has only one context: "microk8s-cluster", but we could create others and refer to any one of them in our operations. The active context is, obviously, defined by this current-context value. You would run the kubectl config set-context command to change this value from the command line.
Now we can download and launch an actual multi-tiered application just like the WordPress project we created in Docker Compose. If anything, it'll take even less work on Kubernetes. I'll begin by adding the Bitnami repository to Helm. Remember, Helm is the Kubernetes package manager, although they prefer to call them charts rather than packages over here.
Here are all the commands we'll use here:
microk8s helm3 repo add bitnami https://charts.bitnami.com/bitnami
microk8s helm3 install wp-site bitnami/wordpress
microk8s kubectl get svc --namespace default -w wp-site-wordpress
microk8s kubectl get all | grep wp
microk8s kubectl get pods
Just use your favorite internet search engine to get the repo URL. Searching for something like "kubernetes chart wordpress bitnami" should do it. That warning about permissions for our config file being too open doesn't bother me all that much in this local test environment. But it should definitely be something to address for public-facing operations. At any rate, bitnami has now been added to my available repos.
One down, one more to go. I just need to tell helm3 to install the wordpress application from the bitnami repo. I'll call the service "wp-site".
The output is important, here. We're told that the status is deployed. There's the endpoint we'd use to point other Kubernetes resources to the service. Those three echo commands will give us everything we'd need to get to the site on a regular browser. I'm not going to bother with that. But you can also get your login credentials by running those two final echo commands. Everything we'll need to know is conveniently provided for us right out of the box.
We're also shown the command we'd need to check the service status. Oh. Right. I should have added microk8s at the beginning. That shows the service is running, but that it hasn't yet received an external IP address. I'll hit CTRL-c to back out of this one.
The get all command will give us the status for all resources with wp in the name. That'll include pods, services, deployments, and replicasets. There are two pods and two services, of course, because we're running both WordPress and MariaDB.
One final general diagnostic command and this demo will be done. kubectl get pods will output all current pods. This can be helpful if you want to dig deeper into a particular resource but you can't remember its exact name. And it looks cool, too.
I hope you've enjoyed everything you've learned here in this course. Be in touch with questions or your own experiences!
Don't miss any of my courses here on Thinkster: