How to Deploy Fusion on Azure Kubernetes Service (AKS)
- Set up the AKS CLI tools
- Azure Prerequisites
- Set up Fusion on AKS
- Upgrade Fusion on AKS
- Verifying the Fusion Installation
setup_f5_aks.sh script provided in this repo is strictly optional.
The script is mainly to help those new to Kubernetes and/or Fusion get started quickly.
If you’re already familiar with K8s, Helm, and AKS, then you use Helm directly to install Fusion into an existing cluster or one you create yourself using the process described here.
If you’re new to Azure, then please visit https://azure.microsoft.com/en-us/free/search/ to set up an account.
Set up the AKS CLI tools
Before launching an AKS cluster, you need to install and configure
az using the links provided below:
To confirm your account access and command-line tools are set up correctly, run the
az login command (
az login –help to see available options).
To launch a cluster in AKS (or pretty much do anything with Azure) you need to setup a Resource Group. Resource Groups are a way of organizing and managing related resources in Azure. For more information about resource groups, see https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview#resource-groups.
You also need to choose a location where you want to spin up your AKS cluster, such as
westus2. For a list of locations you can choose, see https://azure.microsoft.com/en-us/global-infrastructure/locations/.
Use the Azure console in your browser to create a resource group, or simply do:
az group create -g $AZURE_RESOURCE_GROUP -l $AZURE_LOCATION
Azure Account set up.
az) command-line tools installed.
Created an Azure Resource Group and selected a location to launch the cluster.
Set up Fusion on AKS
Download and run the
setup_f5_aks.sh script to install Fusion 5.x in a AKS cluster. To create a new cluster and install Fusion, simply do:
./setup_f5_aks.sh -c <cluster_name> -p <aks_resource_group>
If you don’t want the script to create a cluster, then you need to create a cluster before running the script and simply pass the name of the existing cluster using the
--help option to see full script usage.
By default, our script installs Fusion into the default namespace; think of a K8s namespace as a virtual cluster within a physical cluster. You can install multiple instances of Fusion in the same cluster in separate namespaces. However, please do not install more than one Fusion release in the same namespace.
You can override the namespace using the
-n option. In addition, our script uses f5 for the Helm release name; you can customize this using the
-r option. Helm uses the release name you provide to track a specific instance of an installation, allowing you to perform updates and rollback changes for that specific release only.
You can also pass the
--preview option to the script, which enables soon-to-be-released features for AKS, such as deploying a multi-zone cluster across 3 availability zones for higher availability guarantees. For more information about the Availability Zone feature, see https://docs.microsoft.com/en-us/azure/aks/availability-zones.
It takes a while for AKS to spin up the new cluster. The cluster will have three Standard_D4_v3 nodes which have 4 CPU cores and 16 GB of memory. Behind the scenes, our script calls the
az aks create command.
After running the
setup_f5_aks.sh script, proceed to Verifying the Fusion Installation.
setup_f5_aks.sh script exposes the Fusion proxy service on an external IP over HTTP. This is done for demo or getting started purposes. However, you’re strongly encouraged to configure a K8s Ingress with TLS termination in front of the proxy service.
-h <hostname> options to have our script create an Ingress with a TLS certificate issued by Let’s Encrypt.
Upgrades and Ingress
If you used the
To make things easier for you when upgrading, you should add the settings from this file into your main custom values yaml file. For example:
api-gateway: service: type: "NodePort" ingress: enabled: true host: "<hostname>" tls: enabled: true annotations: "networking.gke.io/managed-certificates": "<RELEASE>-managed-certificate" "kubernetes.io/ingress.class": "gce"
This way, you don’t have to remember to pass the additional
tls-values.yaml file when upgrading.
Upgrade Fusion on AKS
During installation, the script generates a file named
aks_<cluster>_<release>_fusion_values.yaml. Use this file to customize Fusion settings. After making changes to this file, run the following command:
./setup_f5_aks.sh -c <existing_cluster> -p <aks_resource_group> -r <release> -n <namespace> \ --values aks_<cluster>_<release>_fusion_values.yaml --upgrade
You will also use the
--upgrade option to upgrade to a newer version of Fusion.
Verifying the Fusion Installation
In this section, we provide some tips on how to verify the Fusion installation. First, let’s review some useful kubectl commands.
Useful kubectl commands
When working with Kubernetes on the command-line, it’s useful to create a shell alias for
Set the namespace for
kubectl if not using the default:
kubectl config set-context --current --namespace=<NAMESPACE>
This saves you from having to pass
-n with every command.
Get a list of running pods:
k get pods
Get logs for a pod using a label:
k logs –l app.kubernetes.io/component=query-pipeline
Get pod deployment spec and details:
k get pods <pod_id> -o yaml
Get details about a pod events:
k describe po <pod_id>
Port forward to a specific pod:
k port-forward <pod_id> 8983:8983
SSH into a pod:
k exec -it <pod_id> — /bin/bash
CPU/Memory usage report for pods:
k top pods
Forcefully kill a pod:
k delete po <pod_id> --force --grace-period 0
Scale up (or down) a deployment:
k scale deployment.v1.apps/<id> --replicas=N
Check Fusion Pods and Services
Once the install script completes, you can check that all pods and services are available using:
kubectl get pods
If all goes well, you should see a list of pods similar to:
NAME READY STATUS RESTARTS AGE f5-admin-ui-669bb68f74-pjqtw 1/1 Running 0 19h f5-api-gateway-6f7fdd69d-bt2nc 1/1 Running 0 19h f5-auth-ui-b4dfd4f6d-f9tb6 1/1 Running 0 19h f5-classic-rest-service-0 1/1 Running 1 19h f5-devops-ui-768cf6f55b-wphsw 1/1 Running 0 19h f5-fusion-admin-5888f54447-hprt6 1/1 Running 0 19h f5-fusion-indexing-76dfb65dfd-929f4 1/1 Running 0 19h f5-insights-686464b75b-6pzw5 1/1 Running 0 19h f5-job-launcher-5d84c859c4-dl7s9 1/1 Running 0 19h f5-job-rest-server-fb99fcfd7-lmqvd 1/1 Running 0 19h f5-logstash-0 1/1 Running 0 19h f5-ml-model-service-8574b96c68-jqt88 2/2 Running 0 17h f5-query-pipeline-77956f56f8-22wg7 1/1 Running 0 19h f5-rest-service-77ff7d45-rbrn4 1/1 Running 0 19h f5-rpc-service-67b6f4bf49-2d65g 1/1 Running 1 19h f5-rules-ui-65d59dc5b4-5ntq9 1/1 Running 0 19h f5-solr-0 1/1 Running 0 19h f5-webapps-7d9497c485-bbtg9 1/1 Running 0 19h f5-zookeeper-0 1/1 Running 0 19h
The number of pods per deployment / statefulset will vary based on your cluster size and replicaCount settings in your custom values yaml file.
Also, don’t worry if you see some pods having been restarted as that just means they were too slow to come up and Kubernetes killed and restarted them.
You do want to see at least one pod running for every service. If a pod is not running after waiting a sufficient amount of time,
kubectl logs <pod_id> to see the logs for that pod; to see the logs for previous versions of a pod, use:
kubectl logs <pod_id> -p.
You can also look at the actions Kubernetes performed on the pod using
kubectl describe po <pod_id>.
To see a list of Fusion services, do:
kubectl get svc
For an overview of the various Fusion 5 microservices, see: https://doc.lucidworks.com/fusion-server/5.0/deployment/kubernetes/microservices.html