Shameless advertising: I have a new blog post on Red Hat Developers: "Troubleshooting Red Hat OpenShift applications with throwaway containers" https://developers.redhat.com/blog/2019/08/22/troubleshooting-red-hat-openshift-applications-with-th...
This is a terrific approach and a safer alternative to the traditional ssh or exec debugging tactics.
Hi @joelbirchler ,
Even more than you think: OpenShift 4 also provides the 'oc debug node' command, that creates a privileged container in a host of your choice, with the explicit intent to avoid the need to SSH into a worker or master node.
Of course this ability is restricted to cluster admins, but it allows you to perform operations such as looking at the real configuration files that Ignitionand MachineOperators created on your CoreOS nodes, managing systemd units, and using te crictl command to work with the CRI-O container engine in a low-level.
Your cluster nodes are not required to have public IP addresses (and they usually don't) because 'oc debug node' uses the same network path the oc comand uses to connect to the OpenShift API, and them the master nodes tunnel transparently to worker nodes.
This feature was left out of the post because it is sysadmin/cluster admin stuff, not application developer stuff
There is a lot to learn about administering and troubleshooting OpenShift. This infographic provides a description of the learning paths offered by Red Hat Training:
The administration curriculum is in the process of being updated and expanded for OpenShift 4 and updated releases of DO180 and DO280 are already available.