Accessing the details of the software defined networking features of OpenShift can be helpful for deeper troubleshooting or enhanced understanding. You’ll not find a full explanation of Open Virtual Network or OVN-Kubernetes here, but you will learn how to quickly peer inside and investigate their inner workings.
OpenShift Containter Platform 4 is much more like Tectonic than OpenShift 3. Particularly when it comes to installation and node management. Rather then building machines and running an Ansible playbook to configure them you now have the option of setting a fewer paramters in an install config running an installer to build and configure the cluster from scratch. I would like to illustrate how the basics of the networking might look when installing OpenShift on OpenStack.
OpenStack supports “provider” networks, which are networks that pre-exist in your physical infrastructure and are “provided” to the cloud users rather than created by the user. Only an admin is permitted to create a provider network. A prequisite is the provider network must be plumbed to the external bridge on your controller and nova nodes. Here is an Ansible playbook to create a project, place a unshared provider network and subnet in that project.
OpenShift HA Routing uses haproxy application routers to get traffic into the cluster. These application routers are made redundant by running ipfailover (keepalived) pods to maintain a set of Virtual IPs on each infrastructure node where the application routers run. These VIPs are then referenced by round robin DNS records to enable a measure of load balancing. OK, so now you are load balancing at the network layer, but what about the link layer?
Highly availabile containers in OpenShift are baked into the cake thanks to replication controllers and service load balancing, but there are plenty of other single points of failure. Here is how to eliminate many of those. Single Points of Failure The components of OpenShift include: Master controller manager server and API endpoint Etcd configuration and state storage Docker Registry Router haproxy This post is mostly about adding high availability to the routing layer.
With as many grey whiskers as I have, you would think I could grok SNMP in my sleep by now. Unfortunately, everytime I have to deal with it I get frustrated, wonder where the hell my notes from last time are, and start cursing. From now on, here are my notes! I’m typically using Zabbix to poll SNMP OIDs and place the MIBs on the Zabbix server or the Zabbix proxy responsible for SNMP in /usr/share/snmp/mibs.
Copyright (c) 2021, Dale Bewley; all rights reserved.
Template by Bootstrapious. Ported to Hugo by DevCows.
