To run Kuma on OpenShift, you need to download a compatible version of Kuma for the machine from which you will be executing the commands.
You can run the following script to automatically detect the operating system and download Kuma:
curl -L https://kuma.io/installer.sh |sh -
1
You can also download the distribution manually. Download a distribution for the client host from where you will be executing the commands to access OpenShift:
Once downloaded, you will find the contents of Kuma in the kuma- folder. In this folder, you will find - among other files - the bin directory that stores the executables for Kuma, including the CLI client kumactl.
Note: On OpenShift - of all the Kuma binaries in the bin folder - we only need kumactl.
So we enter the bin folder by executing:
cd kuma-1.2.3/bin
1
We suggest adding the kumactl executable to your PATH so that it's always available in every working directory. Or - alternatively - you can also create link in /usr/local/bin/ by executing:
ln -s $PWD/kumactl /usr/local/bin/kumactl
1
Finally we can install and run Kuma in either standalone or multi-zone mode:
Standalone mode is perfect when running Kuma in a single cluster across one environment:
Starting from version 4.1 OpenShift utilizes nftables instead of iptables. So using init container for redirecting traffic to the proxy is no longer works. Instead, we use kuma-cni which could be installed with --cni-enabled flag.
Standalone mode is perfect when running Kuma in a single cluster across one environment.
By default MutatingAdmissionWebhook and ValidatingAdmissionWebhook are disabled on OpenShift 3.11.
In order to make it work add the following pluginConfig into /etc/origin/master/master-config.yaml on the master node:
After updating master-config.yaml restart the cluster and install control-plane:
./kumactl install control-plane | oc apply -f -
1
Multi-zone mode is perfect when running one deployment of Kuma that spans across multiple Kubernetes clusters, clouds and VM environments under the same Kuma deployment.
This mode also supports hybrid Kubernetes + VMs deployments.
Kuma (kuma-cp) will be installed in the newly created kuma-system namespace! Now that Kuma has been installed, you can access the control-plane via either the GUI, oc, the HTTP API, or the CLI:
Kuma ships with a read-only GUI that you can use to retrieve Kuma resources. By default the GUI listens on the API port and defaults to :5681/gui.
To access Kuma we need to first port-forward the API service with:
You can use the kumactl CLI to perform read-only operations on Kuma resources. The kumactl binary is a client to the Kuma HTTP API, you will need to first port-forward the API service with:
You will notice that Kuma automatically creates a Mesh entity with name default.
Kuma explicitly specifies UID for kuma-dp sidecar to avoid capturing traffic from kuma-dp itself. For that reason, nonrootSecurity Context Constraint(opens new window) has to be granted to the application namespace:
If namespace is not configured properly, we will see following error on the Deployment or DeploymentConfig
'pods "kuma-demo-backend-v0-cd6b68b54-" is forbidden: unable to validate against any security context constraint: [spec.containers[1].securityContext.securityContext.runAsUser: Invalid value: 5678: must be in the ranges: [1000540000, 1000549999]]'