Charmed Kubernetes on Azure

Charmed Kubernetes will run seamlessly on Microsoft Azure ^®. With the addition of the azure-integrator, your cluster will also be able to directly use Azure native features.

Azure integrator

The azure-integrator charm simplifies working with Charmed Kubernetes on Azure. Using the credentials provided to Juju, it acts as a proxy between Charmed Kubernetes and the underlying cloud, granting permissions to dynamically create, for example, storage.

Installing using the Out-of-Tree Providers

If you install Charmed Kubernetes using the Juju bundle, you can add the azure-cloud-provider at the same time by using the following overlay file (download it here):

description: Charmed Kubernetes overlay to add native Azure support.
applications:
  kubernetes-control-plane:
    options:
      register-with-taints: ""
      allow-privileged: "true"
  azure-integrator:
    charm: azure-integrator
    num_units: 1
    trust: true
  azure-cloud-provider:
    charm: azure-cloud-provider

relations:
- - azure-cloud-provider:certificates
  - easyrsa:client   # or whichever application supplies cluster certs
- - azure-cloud-provider:kube-control
  - kubernetes-control-plane:kube-control
- - azure-cloud-provider:external-cloud-provider
  - kubernetes-control-plane:external-cloud-provider
- - azure-cloud-provider:azure-integration
  - azure-integrator:clients

To use this overlay with the Charmed Kubernetes bundle, it is specified during deploy like this:

juju deploy charmed-kubernetes --overlay azure-cloud-overlay.yaml --trust

Installing using In-Tree Providers

The Kubernetes binaries have in-tree providers for common cloud platforms, and Azure is no different. The in-tree providers are less flexible, deprecated, and will eventually cease to operate. It’s recommended to use the out-of-tree providers because of this.

If you install Charmed Kubernetes using the Juju bundle, you can add the azure-integrator alone at the same time by using the following overlay file (download it here):

description: Charmed Kubernetes overlay to add native Azure support.
applications:
  azure-integrator:
    annotations:
      gui-x: "600"
      gui-y: "300"
    charm: azure-integrator
    num_units: 1
    trust: true
relations:
  - ['azure-integrator', 'kubernetes-control-plane:azure']
  - ['azure-integrator', 'kubernetes-worker:azure']

To use this overlay with the Charmed Kubernetes bundle, it is specified during deploy like this:

juju deploy charmed-kubernetes --overlay azure-overlay.yaml --trust

Installation Notes

After installation, remember to fetch the configuration file!

juju scp kubernetes-control-plane/0:config ~/.kube/config

Storage

This section describes creating a busybox pod with a persistent volume claim backed by Azure’s Disk Storage. Differenced between the In-tree and Out-of-Tree storage will be noted in each step.

1. Create a storage class:

• Out-of-Tree uses the azuredisk-csi-provisioner provisioner and a storage class is already prepared.

  kubectl describe sc csi-azure-default
  

• In-Tree uses the kubernetes.io/azure-disk provisioner

  kubectl create -f - <<EOY
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: csi-azure-default
  provisioner: kubernetes.io/azure-disk
  parameters:
    storageaccounttype: Standard_LRS
    kind: managed
  EOY
  

2. Create a persistent volume claim using that storage class:

kubectl create -f - <<EOY
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: testclaim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Mi
  storageClassName: csi-azure-default
EOY

3. Create the busybox pod with a volume using that PVC:

kubectl create -f - <<EOY
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
    - image: busybox
      command:
        - sleep
        - "3600"
      imagePullPolicy: IfNotPresent
      name: busybox
      volumeMounts:
        - mountPath: "/pv"
          name: testvolume
  restartPolicy: Always
  volumes:
    - name: testvolume
      persistentVolumeClaim:
        claimName: testclaim
EOY

Charmed Kubernetes can make use of additional types of storage - for more information see the storage documentation.

Azure load-balancers for services

The following commands start the ‘hello-world’ pod behind an Azure-backed load-balancer.

Here are the commands for Kubernetes 1.18+ and above as the kubectl run command was deprecated:

# Kubernetes 1.18+
kubectl create deployment hello-world --image=gcr.io/google-samples/node-hello:1.0 --port=8080
kubectl expose deployment hello-world --type=LoadBalancer --name=hello
watch kubectl get svc -o wide --selector=app=hello-world

Here are the commands for Kubernetes 1.17 and below where the kubectl run command can be used:

# Kubernetes 1.17 and below
kubectl run hello-world --replicas=5 --labels="run=load-balancer-example" --image=gcr.io/google-samples/node-hello:1.0  --port=8080
kubectl expose deployment hello-world --type=LoadBalancer --name=hello
watch kubectl get svc hello -o wide

You can then verify this works by loading the described IP address (on port 8080!) in a browser.

For more configuration options and details of the permissions which the integrator uses, please see the azure-integrator charm page and azure-cloud-provider charm page.

Azure load-balancers for the control plane

With revision 1015 and later of the kubernetes-control-plane charm, Charmed Kubernetes can also use Azure native load balancers in front of the control plane, replacing the need to deploy the kubeapi-load-balancer charm. The kubernetes-control-plane charm supports two relation endpoints, loadbalancer-external for a publicly accessible load balancer which can be used by external clients as well as the control plane, and loadbalancer-internal for a non-public load balancer which can only be used by the rest of the control plane but not by external clients.