OpenShift
Stumbling into Azure Part II: Setting up a private ARO cluster
Toni Schmidbauer
In Part I of our blog post we covered setting up required resources in Azure. Now we are finally going to set up a private cluster. Private
As review from Part I here is our planned setup, this time including the ARO cluster.
Azure Setup
The diagram below depicts our planned setup:
On the right hand side can see the resources required for our lab:
- a virtual network (vnet 192.168.128.0/19). This vnet will be split into 3 separate subnets
- a master subnet (192.168.129.0/24) holding the ARO control plane nodes
- a node subnet (192.168.130.0/24) holding ARO worker nodes
- and finally a subnet call
GatewaySubnetwhere we are going to deploy our Azure VPN gateway (called avnet-gateway)The subnet where the Azure VPN gateway is located needs to have the name
GatewaySubnet. Otherwise creating the Azure VPN gateway will fail.Read More ...Stumbling into Azure Part I: Building a site-to-site VPN tunnel for testing
So we want to play with ARO (Azure Red Hat OpenShift) private clusters. A private cluster is not reachable from the internet (surprise) and is only reachable via a VPN tunnel from other networks.
This blog post describes how we created a site-to-site VPN between a Hetzner dedicated server running multiple VM's via libvirt and Azure.
An upcoming blog post is going to cover the setup of the private ARO cluster.
Read More ...Secure your secrets with Sealed Secrets
Working with a GitOps approach is a good way to keep all configurations and settings versioned and in sync on Git. Sensitive data, such as passwords to a database connection, will quickly come around. Obviously, it is not a idea to store clear text strings in a, maybe even public, Git repository. Therefore, all sensitive information should be stored in a secret object. The problem with secrets in Kubernetes is that they are actually not encrypted. Instead, strings are base64 encoded which can be decoded as well. Thats not good … it should not be possible to decrypt secured data. Sealed Secret will help here…
Read More ...Introduction
Pod scheduling is an internal process that determines placement of new pods onto nodes within the cluster. It is probably one of the most important tasks for a Day-2 scenario and should be considered at a very early stage for a new cluster. OpenShift/Kubernetes is already shipped with a default scheduler which schedules pods as they get created accross the cluster, without any manual steps.
However, there are scenarios where a more advanced approach is required, like for example using a specifc group of nodes for dedicated workload or make sure that certain applications do not run on the same nodes. Kubernetes provides different options:
Controlling placement with node selectors
Controlling placement with pod/node affinity/anti-affinity rules
Controlling placement with taints and tolerations
Controlling placement with topology spread constraints
This series will try to go into the detail of the different options and explains in simple examples how to work with pod placement rules. It is not a replacement for any official documentation, so always check out Kubernetes and or OpenShift documentations.
Read More ...Node Affinity
Node Affinity allows to place a pod to a specific group of nodes. For example, it is possible to run a pod only on nodes with a specific CPU or disktype. The disktype was used as an example for the
nodeSelectorand yes … Node Affinity is conceptually similar to nodeSelector but allows a more granular configuration.Read More ...NodeSelector
One of the easiest ways to tell your Kubernetes cluster where to put certain pods is to use a
nodeSelectorspecification. A nodeSelector defines a key-value pair and are defined inside the specification of the pods and as a label on one or multiple nodes (or machine set or machine config). Only if selector matches the node label, the pod is allowed to be scheduled on that node.Read More ...Pod Affinity/Anti-Affinity
While noteSelector provides a very easy way to control where a pod shall be scheduled, the affinity/anti-affinity feature, expands this configuration with more expressive rules like logical AND operators, constraints against labels on other pods or soft rules instead of hard requirements.
The feature comes with two types:
pod affinity/anti-affinity - allows constrains against other pod labels rather than node labels.
node affinity - allows pods to specify a group of nodes they can be placed on
Read More ...Taints and Tolerations
While Node Affinity is a property of pods that attracts them to a set of nodes, taints are the exact opposite. Nodes can be configured with one or more taints, which mark the node in a way to only accept pods that do tolerate the taints. The tolerations themselves are applied to pods, telling the scheduler to accept a taints and start the workload on a tainted node.
A common use case would be to mark certain nodes as infrastructure nodes, where only specific pods are allowed to be executed or to taint nodes with a special hardware (i.e. GPU).
Read More ...Copyright © 2020 - 2025 Toni Schmidbauer & Thomas Jungbauer
Thomas Jungbauer