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
charm 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:azure-integration', 'azure-integrator:clients' ]
- [ 'azure-cloud-provider:external-cloud-provider', 'kubernetes-control-plane:external-cloud-provider' ]
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
… and remember to fetch the configuration file!
juju ssh kubernetes-control-plane/leader -- cat config > ~/.kube/config
For more configuration options and details of the permissions which the integrator uses, please see the charm readme.
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 ssh kubernetes-control-plane/leader -- cat 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
provisionerkubectl 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.
See the guide to contributing or discuss these docs in our public Mattermost channel.