What’s Helm?
Helm is a tool that streamlines the installation and management of applications on Kubernetes platforms. The Couchbase Autonomous Operator helm chart allows users to combine Kubernetes definitions for resources like Services, Roles, and Deployments into a single customizable package. Since Helm is essentially a package manager for Kubernetes applications, all installed resources can be managed and updated as a single unit using an all-or-nothing approach which ensures every dependency needed for each release is successfully installed when upgrading. This blog describes how to use Helm for installing the Couchbase Autonomous Operator along with a Couchbase Cluster into your Kubernetes environment.
Installing Helm
Assuming you have a kubernetes cluster running on at least version 1.11, then you’re all set to get started with helm for deploying a Couchbase Cluster. The first step is to install the Helm command line client. The following commands will download and unpack the helm binary to an executable path for linux (for a different OS see releases)
1 2 3 4 |
# Install helm wget https://storage.googleapis.com/kubernetes-helm/helm-v2.13.1-linux-amd64.tar.gz tar -zxvf helm-v2.13.1-linux-amd64.tar.gz sudo mv linux-amd64/helm /usr/local/bin/helm |
Now let’s install Helms templating service which is called tiller
. Tiller does all the work of interacting directly with the Kubernetes API for creating resources like Services, Secrets, and Pods. As with every good quick-start guide, we’re going to be a bit loose with security for the sake of brevity, which means giving the tiller
service the ability to create resources within any Kubernetes namespace. Run the following command to create the RBAC rules and ServiceAccount needed for the Tiller service:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
echo "apiVersion: v1 kind: ServiceAccount metadata: name: tiller namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: tiller roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: tiller namespace: kube-system" | kubectl create -f - |
Finally install the tiller service into the kubernetes cluster:
1 |
helm init --service-account tiller |
Time to start helming!
Installing Charts
Install the Operator Chart
The Couchbase Operator Chart deploys the dynamic admission controller, the Operator itself, and every resource needed to run them within your cluster. This is the power/magic of helm, as it functions very similar to a package manager by representing a group of resources as a single installable, and upgradeable unit.
To install the charts you will need to point the helm client to our partner repository with the following command:
1 |
helm repo add couchbase https://couchbase-partners.github.io/helm-charts/ |
And now let’s install the operator chart:
1 |
helm install --name op-example couchbase/couchbase-operator |
The install returns a list of commands to run for checking logs of the operator.
1 2 3 4 5 6 7 |
NOTES: 1. couchbase-operator deployed. Check the couchbase-operator logs kubectl logs -f deployment/op-example-couchbase-operator --namespace default 2. admission-controller deployed. Check the admission-controller logs kubectl logs -f deployment/op-example-couchbase-admission-controller --namespace default |
Copy the first command to ensure that the operator has started successfully:
1 |
kubectl logs -f deployment/op-example-couchbase-operator --namespace default |
And you should see that the operator is listening for events, which means that it’s waiting for a cluster to manage:
1 2 3 |
time="2019-05-02T23:42:12Z" level=info msg="couchbase-operator v1.2.0 (release)" module=main ... time="2019-05-02T23:42:28Z" level=info msg="CRD initialized, listening for events... |
Install the Couchbase Cluster Chart
The couchbase cluster chart provides a templated version of the couchbase cluster type. By default, this chart will install a 3 node cluster. If you’re curious about the details of this chart you can view the default values with the following command:
1 |
helm inspect couchbase/couchbase-cluster |
Now let’s get a cluster running by installing the cluster chart with the following command:
1 |
helm install --name cb-example couchbase/couchbase-cluster |
The install returns steps to get status of the cluster along with a quick way to view the Admin console.
1 2 3 4 5 6 |
NOTES: 1. Get couchbase cluster status kubectl describe --namespace default couchbasecluster cb-example-couchbase-cluster 2. Connect to Admin console kubectl port-forward --namespace default cb-example-couchbase-cluster-0000 8091:8091 # open http://localhost:8091 |
Let’s run the 2nd command to view the console:
1 |
kubectl port-forward --namespace default cb-example-couchbase-cluster-0000 8091:8091 |
This command will create a proxy of the Admin console to your localhost at port 8091. Navigate to http://localhost:8091 to view the cluster. If you do not yet see the cluster, run kubectl describe po cb-example-couchbase-cluster-0000 to get status of the Pod being forwarded because it may be that images are still being created, which is often the case when running on a brand new cluster.
Managing Charts
At this point you should have at least two charts installed, one for the operator and another for the cluster. To view the list of installed charts run helm list
:
1 2 3 4 5 |
~$ helm list NAME REVISION UPDATED STATUS CHART APP VERSION NAMESPACE cb-example 1 Thu May 9 23:44:31 2019 DEPLOYED couchbase-cluster-0.1.2 1.2 default op-example 1 Thu May 9 23:40:36 2019 DEPLOYED couchbase-operator-0.1.2 1.2 default |
When a chart is installed it is referred to by Helm as a release
. You can install multiple releases from a single chart. When a release is deleted using helm delete
, all of it’s packaged resources (Pods, Services, Secrets) are also deleted. For more information about customizing the operator and cluster chart, refer to the Couchbase Operator documentation on Updating a Release.
Installing with TLS and Persistent Volumes
To create a cluster with TLS and Persistent Volumes we’ll use helm’s template overriding to provide customizations of the cluster chart.
Create a file named myvalues.yaml
with the following values:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
echo "couchbaseCluster: servers: all_services: pod: volumeMounts: default: couchbase data: couchbase securityContext: fsGroup: 1000 volumeClaimTemplates: - metadata: name: couchbase spec: storageClassName: default resources: requests: storage: 1Gi couchbaseTLS: create: true" > myvalues.yaml |
The above values assume you have a storage class named default
, if this is not the case then change it to the appropriate value for your environment. Now install the cluster chart with the value overrides:
1 |
helm install --name cbs-example -f myvalues.yaml couchbase/couchbase-cluster |
Notice helm auto-generated the CA cert used by the operator and clients along with the server cert and key.
1 2 3 4 5 6 |
RESOURCES: ==> v1/Secret NAME AGE cbs-example-couchbase-cluster 1s cbs-example-couchbase-cluster-server-tls 1s cbs-example-couchbase-cluster-operator-tls 1s |
To view the Admin console, run the port forward command from the TLS enabled admin port (18091) of a pod to your localhost with the following command:
1 |
kubectl port-forward --namespace default cbs-example-couchbase-cluster-0000 18091:18091 |
Navigate to http://localhost:18091 to view the cluster.
Moving on
If you’re thinking, “that was too easy,” you’re probably right. If you’re thinking, “I want to know more”, then have a look at the Setup Guide for best practices on taking your environment in to production!
More Couchbase Autonomous Operator Resources
-
Try it out: https://www.couchbase.com/downloads
-
Support forums: https://www.couchbase.com/forums/c/couchbase-server/Kubernetes
-
Documentation: https://docs.couchbase.com/operator/1.2/whats-new.html
Read More
-
Autonomous Operator 1.2.0 Deep Dive: https://www.couchbase.com/blog/deep-dive-couchbase-autonomous-operator-1-2-0
-
Autonomous Operator 1.2.0 Networking: https://www.couchbase.com/blog/autonomous-operator-1-2-0-networking