Your submission was sent successfully! Close

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

A standard install of Charmed Kubernetes will use more resources than the current quotas allocated to a new Azure account. If you see error messages saying allocating machines would exceed your quota, you will need to log a support request with Azure to increase the quota accordingly.

Resource usage:

By relating to this charm, other charms can directly allocate resources, such as managed disks and load balancers, which could lead to cloud charges and count against quotas. Because these resources are not managed by Juju, they will not be automatically deleted when the models or applications are destroyed, nor will they show up in Juju's status or GUI. It is therefore up to the operator to manually delete these resources when they are no longer needed, using the Azure management website or API.

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.

We appreciate your feedback on the documentation. You can edit this page or file a bug here.