Adding support for Windows nodes in your OpenShift cluster is a day 2 operation that requires preparation at install time. It is important to accommodate the hybrid networking requirements for Windows Kubernetes nodes. Azure specific tasks and gotchas are highlighted in this part 1 of 3 while laying the groundwork applicable to deploying OpenShift on any provider in preparation for managing Windows containers.
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?
This is a work in progress The OpenShift Container Platform (OCP) can run on many types of infrastructure; from a Docker contrainer, to a single VM, to a fleet of baremetal or VMs on an infrastructure provider such as RHV, VMware, Amazon EC2, Google Compute Engine, or OpenStack Platform (OSP). This post is to document my experimentation with setting up OCP on OSP. Doc Overview So where are the docs?
I needed to host a service that would be consumed by a closed client that insists on speaking HTTPS on port 50,000. To solve this, I added a 2nd router deployment and used the OpenShift router sharding feature to selectively enable routes on the 2nd router by way of selectors. To summarize: Existing HA router: HTTP 80 HTTPS 443 Haproxy Stats 1,936 Added HA router: HTTP 49,999 HTTPS 50,000 Haproxy Stats 51,936 How To Open infra node firewalls Open firewall on infra nodes where router will run to allow new http and https port iptables -A OS_FIREWALL_ALLOW -m tcp -p tcp --dport 49999 -j ACCEPT iptables -A OS_FIREWALL_ALLOW -m tcp -p tcp --dport 50000 -j ACCEPT This can also be done with Ansible and the os_firewall role in your playbook.
OpenShift gathers cluster metrics such as CPU, memory, and network bandwidth per pod which can assist in troubleshooting and capacity planning. The metrics are also used to support horizontal pod autoscaling, which makes the metrics service not just helpful, but critical to operation. Missing Liveness Probes There are 3 major components in the metrics collection process. Heapster gathers stats from Docker and feeds them to Hawkular Metrics to tuck away for safe keeping in Cassandra.
Update! I failed with CDK 2.0, but CDK 2.1 works with some fiddling. In my last post I installed Red Hat Container Developer Kit to deploy OpenShift Enterprise using Vagrant. But now I want to add Hawkular Metrics to that deployment. Deploy Metrics Refer to the docs for deploying metrics in OSE. Login to the vagrant CDK VM before continuing $ cd ~/cdk/components/rhel/rhel-ose/ $ vagrant ssh $ oc login Authentication required for https://127.
The RedHat Container Developer Kit allows you to deploy OpenShift on your laptop for easier testing and development. Here is how to deploy it. Register as a RedHat Developer Obtain a RH login Place credentials in ~/.vagrant.d/Vagrantfile to enable updates for VMs by automatically registering with RedHat Subscription Manager Vagrant.configure('2') do |config| config.registration.username = '<your Red Hat username>' config.registration.password = '<your Red Hat password>' end Mac OS X Prereqs Install pre-reqs:
Upgrading from OSE 3.1 to 3.2 using the playbook went quite well for me, but there were a few issues to sort out. The issues were related to: ip failover had to be updated manually there was about 5 minutes downtime during the upgrade updates to image streams docker error messages updated policy and role bindings build strategy Source is not allowed hawkular metrics Upgrade Process Following the directions is pretty straight forward.
OpenShift has an internal CA for generating certificates to authenticate intra-cluster communication, but your browser doesn’t trust this CA. Perhaps you want to fix that without mucking with the internal SSL communication? I did. Here is how. This OpenShift doc explains how to do this, but it isn’t very clear, to me at least. Overview An outline of the steps: Only make changes to the public URLs and not any internal URLs.
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.