Systems and platforms continue to grow more complex and distributed. The march towards distributed microservices has been accelerated with Kubernetes; arm yourself with a Kubernetes manifest and up your replica count and like magic, you have more than one endpoint for your workload. In the Kubernetes ecosystem, there has been a lot of investment on the infrastructure side of the house for example in making sure clusters are performant and have the ability to scale.
Imagine yourself as a new developer on a team that has services on Kubernetes. On your first day in the role, you need to figure out aspects of the application running in Kubernetes. The purview you are granted with kubectl or even Kubernetes-centric tools is still infrastructure-centric. Now with Shipa, that is changing and you can have an application-centric view of your application. Until recently, the application map that Shipa provides was limited to applications that were managed by Shipa. Shipa now has the capability to expose application-centric information for applications not managed by Shipa e.g Application Discovery. In this example, you can wire your first Application Discovery.
Getting Started
For Application Discovery, you need a Shipa or Shipa Cloud instance and a Kubernetes cluster and you are all set. If this is your first time leveraging Shipa, you can sign up for a Shipa Cloud account for free. There are a few tutorials on how to wire Shipa Cloud to a Kubernetes cluster or even to a local Kubernetes cluster on your machine. This example will walk you through assuming you have a vanilla Kubernetes cluster.
Deploy Some Workload to Your Cluster
First validating you have connectivity to your Kubernetes cluster of choice, can run kubectl get nodes.
Next as a good habit, create a Namespace to deploy your workload.
kubectl create namespace notdefault
A quick way to deploy a sample workload is to deploy Bitnami’s WordPress Helm Chart. If you don’t have Helm, you can grab Helm via a tool like Homebrew.
helm repo add bitnami https://charts.bitnami.com/bitnami helm repo update helm install my-release bitnami/wordpress --namespace notdefault
Then you can validate the pods are up and running.
kubectl get pods -n notdefault
Now you are ready to create a Shipa Framework that will discover your applications.
Shipa Application Discovery Framework
Shipa works off a concept of Frameworks which are logical groupings of policies. Application Discovery works off of ingesting Labels. The first step can be to either look at what Labels are attached to your Pods or add Labels to your Pod.
To view Labels on your Pods:
kubectl get pods -n notdefault --show-labels
Depending on where you get your workload, could be an exercise at looking at an eyechart. Though for this Bitnami Helm Chart, the label “app.kubernetes.io/name” is common across both Pods. We will use that Label in Shipa.
Optionally, you can add your own Labels also.
kubectl label pods -n notdefault <pod> somelabel=somevalue
Now it is time to create a Shipa Framework to ingest Labels.
Shipa -> Frameworks + Add Framework
In the UI can select “Discover existing applications” then click Next.
In the General Configuration:
Name: discovernotdefault
Kubernetes Namespace: notdefault
Ingress: traefik [this is Shipa’s Default to bind a cluster, will be set up later]
Plan: shipa-plan [default created with Shipa Cloud]
Team: shipa-team [default created with Shipa Cloud].
Click Next and configure the auto-discovery [label] information so Shipa can discover the applications.
Label: app.kubernetes.io/name
Then click Create and your Framework is available.
Now you are ready to wire your Kubernetes cluster to Shipa.
Wiring a Kubernetes Cluster to Shipa
Wiring a Kubernetes cluster is simple and will require three pieces; the Kubernetes API endpoint, service account token, and CA Cert.
Shipa Cloud -> Clusters + Connect Cluster
In Cluster Setup
Name: somekubernetescluster
Framework: discovernotdefault
In the Cluster Connection Screen, finding the three pieces are straightforward.
Kubernetes Control Plane
This is your Kubernetes API Endpoint address.
kubectl cluster-info | grep 'Kubernetes' | awk '/http/ {print $NF}'
Token
A service account is needed to be created and then a token generated off of that service account needs to be wired into Shipa. The Shipa Documentation for connecting a cluster gives the needed manifest to create the role and base the token off of.
Create shipa-admin-service-account.yaml
Then apply the manifest.
kubectl apply -f shipa-admin-service-account.yaml
Now you can grab the token off of the account.
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep shipa-admin | awk '{print $1}')
Certificate
Once the token has been created, now you can grab the CA Certificate.
kubectl get secret $(kubectl get secret | grep default-token | awk '{print $1}') -o jsonpath='{.data.ca.crt}' | base64 --decode
Wire in to Shipa
With the three pieces of needed information captured, wire into the Cluster Connection UI.
Click Next and can leverage the default Shipa Traefik ingress controller.
Click Create and your cluster will be wired and the auto-discovery process will be started.
Your First Auto-Discovered Applications View
Navigating to the Applications menu, you should see two new applications appear which were discovered by Shipa without any user or admin intervention.
Shipa is known for providing a world-class application map which you can now dig into and see what has been exposed.
Applications -> wordpress -> Application Map
Shipa has also discovered the backing MariaDB of WordPress. The art of the possible is great with Shipa exposing applications in your organization. Shipa can also manage those applications if deployed through Shipa. This is just our first rendition of Application Discovery and looking to have conformance and compliance features in future renditions. Stay tuned!
Cheers,
-Ravi