Kubernetes

[edit on GitHub]

Kubernetes is an open source container cluster manager that is available as a stand-alone platform or embedded in several distributed platforms including Google’s Container Engine, AWS Elastic Kubernetes Service, Azure Kubernetes Service, and Red Hat OpenShift. Chef Habitat and Kubernetes are complementary. While Kubernetes provides a platform for deployment, scaling, and operations of application containers across clusters of hosts, Chef Habitat manages the build pipeline and lifecycle of those application containers.

Chef Habitat on Kubernetes

Chef Habitat can export your package as a Docker container that runs on Kubernetes in the form of a pod. Additionally, a Chef Habitat bastion pod provides essential gossip ring features like service discovery (binds), secrets and the required initial peer to all other pods.

Chef Habitat robustly deploys the bastion pod with a Kubernetes stateful set, persistent volume, and liveness checking, which ensures node availability and ring data persistence. The Kubernetes stateful set comes with an attached Kubernetes service that makes discoverable with DNS. Each namespace should contain a single service and stateful set.

Deploy the Chef Habitat Bastion on Kubernetes

Complete examples may be downloaded from this folder

To explain how this works, let’s break down the hab-bastion.yaml file:

apiVersion:v1kind:Servicemetadata:name:hab-bastionspec:ports:- name:gossip-listenerprotocol:UDPport:9638targetPort:9638- name:http-gatewayprotocol:TCPport:9631targetPort:9631selector:app:hab-bastionclusterIP:None

This service definition creates a virtual IP (VIP), opening access to the Chef Habitat service that runs on the pod.

• The habitat gossip port (9638/UDP) listener
• The habitat http-gateway (9631/TCP) listener
• makes service name available in DNS (as hab-bastion or hab-bastion.namespace-name, etc) and discoverable by any pod

apiVersion:apps/v1kind:StatefulSetmetadata:name:hab-bastionspec:spec:securityContext:fsGroup:42

This section sets the group ownership for the persistent volume mount point so the Habitat Supervisor can write to it. The Habitat user (hab) by default has the uid 42 and the gid 42.

containers:- name:hab-bastionimage:mydockerorigin/hab_bastion:latestargs:- '--permanent-peer'

The image: line defines the source of the docker container. In this case, the instructions create an image from a Chef Habitat plan using the hab pkg export docker command. It only runs the Chef Habitat Supervisor (hab-sup) service. The argument --permanent-peer instructs the Supervisor to act as a permanent peer.

resources:requests:memory:"100Mi"cpu:"100m"# equivalent to 0.1 of a CPU core

Resource requests are important because they give instructions to the Kubernetes scheduler–without them, you might overload some nodes while under-using others.

ports:- name:gossip-listenerprotocol:UDPcontainerPort:9638- name:http-gatewayprotocol:TCPcontainerPort:9631readinessProbe:httpGet:path:/port:9631initialDelaySeconds:5periodSeconds:10livenessProbe:httpGet:path:/port:9631initialDelaySeconds:15periodSeconds:20

The livenessProbe tells Kubernetes if the pod is healthy or not. If not, the pod gets restarted. The readinessProbe signals to Kubernetes that the pod has started up successfully.

volumeMounts:- name:hab-bastionmountPath:/hab/supvolumeClaimTemplates:- metadata:name:hab-bastionspec:accessModes:["ReadWriteOnce"]# uncomment if you don't have a default StorageClass# storageClassName: "standard"resources:requests:storage:10Gi

All of the Habitat Supervisor’s state data is stored under /hab/sup - we mount this on a persistent volume so it gets re-attached if the pod is ever rescheduled. The data persists!

Create a Kubernetes Deployment That Works with the Bastion

The following is an example of a Kubernetes Stateful Set built from the CockroachDB plan. The Bastion pattern uses the --peer hab-bastion configuration arguments to instruct the Kubernetes pods to use the hab-bastion service as a DNS-resolvable host name.

+++apiVersion:apps/v1kind:StatefulSetmetadata:name:cockroachdbspec:selector:matchLabels:app:cockroachdbserviceName:cockroachdbreplicas:3template:metadata:labels:app:cockroachdbspec:terminationGracePeriodSeconds:10securityContext:fsGroup:42containers:- name:cockroachdbimage:irvingpop/cockroach:latestargs:- --peer- hab-bastion- --topology- leaderresources:requests:memory:"300Mi"cpu:"500m"ports:- name:httpcontainerPort:8080- name:cockroachdbcontainerPort:26257volumeMounts:- name:cockroachdb-datamountPath:/hab/svc/cockroach/datavolumeClaimTemplates:- metadata:name:cockroachdb-dataspec:accessModes:["ReadWriteOnce"]resources:requests:storage:10Gi

Bare Kubernetes

If your packages don’t require communication with the Chef Habitat Supervisor ring, such as binds, secrets, etc., then you can execute your packages directly on the cluster. You can deploy Chef Habitat packages exported as containers to Kubernetes with the kubectl command. Using the Docker exporter to create a containerized application, you can launch the container like this example:

$ kubectl run mytutorial --image=myorigin/mytutorial --port=8080

Assuming you’re using the Docker image pulled from myorigin/mytutorial, port 8080 on the container should be accessible. Pass networking ports exposed by Chef Habitat with kubectl run as --port options. In this example, the kubectl get command is:

$ kubectl get pods -l run=mytutorial

Docker and ACI

Chef Habitat packages can be exported in both Docker and ACI formats (as well as others). Kubernetes currently supports the Docker runtime and integration of the rkt container runtime (an implementation of the App Container spec) is under active development.

Environment Variables and Networking

Kubernetes supports passing environment variables into containers.

Related Reading

• Export a Chef Habitat package
• Chef Habitat CLI