Tag Archives: openshift

Deploying OpenShift clusters (IPI) using vRA Code Stream

June 30, 2021VMware, KubernetesCode Stream, Deploy, openshift, Tanzu Mission Control, vRADean

This walk-through will detail the technical configurations for using vRA Code Stream to deploy Red Hat OpenShift Clusters, register them as Kubernetes endpoints in vRA Cloud Assembly and Code Stream, and finally register the newly created cluster in Tanzu Mission Control.

The deployment uses the Installer Provisioned Infrastructure method for deploying OpenShift to vSphere. Which means the installation tool “openshift-install” provisions the virtual machines and configures them for you, with the cluster using internal load balancing for it’s API interfaces.

This post mirrors my original blog post on using vRA to deploy AWS EKS clusters.

Pre-reqs

Red Hat Cloud Account
- With the ability to download and use a Pull Secret for creating OpenShift Clusters
vRA access to create Code Stream Pipelines and associated objects inside the pipeline when it runs.
- Get CSP API access token for vRA Cloud or on-premises edition.
Tanzu Mission Control access with ability to attach new clusters
- Get an CSP API access token for TMC
vRA Code Stream configured with an available Docker Host that can connect to the network you will deploy the OpenShift clusters to.
- This Docker container is used for the pipeline
- You can find the Dockerfile here, and alter per your needs, including which versions of OpenShift you want to deploy.
SSH Key for a bastion host access to your OpenShift nodes.
vCenter account with appropriate permissions to deploy OpenShift
- You can use this PowerCLI script to create the role permissions.
DNS records created for OpenShift Cluster
- api.{cluster_id}.{base_domain}
- *.apps.{cluster_id}.{base_domain}
Files to create the pipeline are stored in either of these locations:
- https://github.com/saintdle/vRA-Deploy-OpenShift-Clusters
- https://code.vmware.com/samples?id=7635

High Level Steps of this Pipeline

Create an OpenShift Cluster
- Build a install-config.yaml file to be used by the OpenShift-Install command line tool
- Create cluster based on number of user provided inputs and vRA Variables
Register OpenShift Cluster with vRA
- Create a service account on the cluster
- collect details of the cluster
- Register cluster as Kubernetes endpoint for Cloud Assembly and Code Stream using the vRA API
Register OpenShift Cluster with Tanzu Mission Control
- Using the API

Creating a Code Stream Pipeline to deploy a OpenShift Cluster and register the endpoints with vRA and Tanzu Mission Control

Create the variables to be used

First, we will create several variables in Code Stream, you could change the pipeline tasks to use inputs instead if you wanted. Continue reading Deploying OpenShift clusters (IPI) using vRA Code Stream →

How to install and configure Kasten to protect container workloads on Red Hat OpenShift and VMware vSphere

March 2, 2021Kubernetes, Veeambackup, Configure, container, How to, Install, Kasten, openshift, restoreDean

In this blog post I’m going to cover deploying and configuring Kasten, the container based enterprise backup software now owned by Veeam Software.

This deployment will be inside my Red Hat OpenShift Environment which is running on top of VMware vSphere.

I’ll be protecting a cool gaming application that has data persistence using MongoDB.

Installing Kasten on Red Hat OpenShift

In this guide, I am going to use Helm, you can learn how to install it here.

Create a OpenShift project (Kubernetes namespace) called “kasten-io”

oc new-project kasten-io

Next we are going to use Helm to install the Kasten software into our OpenShift cluster.

helm install k10 kasten/k10 --namespace=kasten-io --set scc.create=true --set route.enabled=true --set route.path="/k10" --set auth.tokenAuth.enabled=true

Breaking down the command arguments;

–set scc.create=true
- This creates the correct Security Contexts against the users created by the install. This is needed in OpenShift as the security context stance is higher OOTB than that of a vanilla Kubernetes install.
–set route.enabled=true
- This creates a route in OpenShift using the default ingress, so that the Kasten dashboard is accessible externally. This will use the default cluster ID domain name.
–set route.path=”/k10″
- This sets the route path for the redirection of the dashboard. Without this, your users will need to go to http://{FQDN}/ and append the path to the end (k10).
–set auth.tokenAuth.enabled=true
- This sets the authentication type of the Kasten Dashboard.

Continue reading How to install and configure Kasten to protect container workloads on Red Hat OpenShift and VMware vSphere →

Enabling Tanzu Mission Control Data Protection on Red Hat OpenShift

February 18, 2021VMware, KubernetesData Protection, openshift, Red Hat, Tanzu, TMCDean

Just a quick blog on how to get the Data Protection feature of Tanzu Mission Control on Red Hat OpenShift. By default you will find that once the data protection feature is enabled, the pods for Restic component of Velero error.

Enable the Data Protection Feature on your Openshift cluster

You will see the UI change to show it’s enabling the feature.

You will see the Velero namespace created in your cluster.

However the “Data Protection is being enabled” message in the TMC UI will continue to show without user intervention. If you show the pods for the Velero namespace you will see they error.

This is because OpenShift has a higher security context out of the box for containers than a vanilla Kubernetes environment.

The steps to resolve this are the same for a native install of the Project Velero opensource install to your cluster.

First we need to add the velero service account to the privileged SCC.

oc adm policy add-scc-to-user privileged -z velero -n velero

Secondly we need to patch the DaemonSet to allow the containers for Restic run in a privileged mode.

oc patch ds/restic \
--namespace velero \
--type json \
-p '[{"op":"add","path":"/spec/template/spec/containers/0/securityContext","value": { "privileged": true}}]'

After this, if we run the command to get all pods under the Velero namespace again, we’ll see that they are replaced with the new configuration and running.

Going back to our TMC Console, we’ll see the Data Protection feature is now enabled.

Regards

Follow @Saintdle

Dean Lewis

How to configure Red Hat OpenShift to forward logs to VMware vRealize Log Insight Cloud

January 15, 2021Kubernetes, VMwareCloud, Forwarding, Log, Log Insight, openshift, vRealizeDean

In this blog post we will cover how to configure Red Hat OpenShift to forward logs from the ClusterLogging instance to an external 3rd party system, in this case, VMware vRealize Log Insight Cloud.

Architecture

The Openshift Cluster Logging will have to be configured for accessing the logs and forwarding to 3rd party logging tools. You can deploy the full suite;

Visualization: Kibana
Collection: FluentD
Log Store: Elasticsearch
Curation: Curator

However, to ship the logs to an external system, you will only need to configure the FluentD service.

To forward the logs from the internal trusted services, we will use the new Log Forwarding API, which is GA in OpenShift 4.6 and later (it was a tech preview in earlier releases, and the configuration YAMLs are slightly different, so read the relevant documentation version).

This setup will provide us the architecture below. We will deploy the trusted namespace “OpenShift-Logging” and use the Operator to provide a Log Forwarding API configuration which sends the logs to a 3rd party service.

For vRealize Log Insight Cloud, we will run a standalone FluentD instance inside of the cluster to forward to the cloud service.

The log types are one of the following:

application. Container logs generated by user applications running in the cluster, except infrastructure container applications.
infrastructure. Container logs from pods that run in the openshift*, kube*, or default projects and journal logs sourced from node file system.
audit. Logs generated by the node audit system (auditd) and the audit logs from the Kubernetes API server and the OpenShift API server.

Prerequisites

VMware vRealize Log Insight Cloud instance setup with Administrator access.
Red Hat OpenShift Cluster deployed
- with outbound connectivity for containers
Download this Github Repository for the configuration files

git clone https://github.com/saintdle/openshift_vrealize_loginsight_cloud.git

Deploy the standalone FluentD instance to forward logs to vRealize Log Insight Cloud

As per the above diagram, we’ll create a namespace and deploy a FluentD service inside the cluster, this will handle the logs forwarded from the OpenShift Logging instance and send the to the Log Insight Cloud instance.

Creating a vRealize Log Insight Cloud API Key

First, we will create an API key for sending data to our cloud instance.

Expand Configuration on the left-hand navigation pane
Select “API Keys”
Click the “New API Key” button

Give your API key a suitable name and click Create.

Continue reading How to configure Red Hat OpenShift to forward logs to VMware vRealize Log Insight Cloud →

OpenShift – Cluster-Monitoring-Operator Pod Error – cannot verify user is non-root

January 13, 2021KubernetesCluster-Monitoring-Operator, Error, non-root, openshiftDean

The issue

After building a brand new OpenShift 4.6.9 cluster, I noticed one of the pods was not running correctly

oc get pods -n openshift-monitoring
.....
NAME READY   STATUS                       RESTARTS   AGE
cluster-monitoring-operator-f85f7bcb5-84jw5 1/2 CreateContainerConfigError 0 112m

Upon inspection of the pod;

oc describe pod cluster-monitoring-operator-XXX -n openshift-
monitoring

I could see the following error message;

Error: container has runAsNonRoot and image has non-numeric user
(nobody), cannot verify user is non-root

The Cause

There is a Red Hat article about this, but it is gated. The reason is cluster-monitoring-operator gets wrongly the non-root SCC assigned.

The Fix

Currently there is no permanent provided fix from Red Hat, but you can track this bug.

However the workaround is to simply delete the pod. This should recreate and load with the correct permissions.