This is a brief overview aimed at system administrators in getting accustomed to what OpenShift actually looks like installed on a host, and a common places to look when things go wrong. What should be running (systemctl) Nodes Masters Viewing Logs Storage Management What’s Next? What should be running (systemctl) At a high level, a host in an OpenShift cluster could include the following components:
After having gone through the process of building an OpenShift environment, it’s important to go through a few validation steps to ensure that all components are in proper working order. This document walks you through those steps. Validate Nodes Validate Status of Default Project Check that Registry Is Running Check that Router is Running Run Diagnostics Create an Application But wait, something didn’t work! Other Resources Validate Nodes # oc get nodes Check the output to ensure that:
OpenShift Monitoring is an ever evolving problem space, with many layers, approaches, and complexities. We attempt to unpack them here. Overview Ensuring a cluster is healthy Docker Nodes & Masters API Endpoints Ensuring a cluster has adequate capacity What’s Next? Overview Note Before reading this guide, we recommend first reading An Overview of OpenShift for System Admins. The following document intends to provide starting guidance on how to build a monitoring approach for OpenShift.
This guide discusses the synchronization of groups defined in an LDAP server with OpenShift and is distinct from using an LDAP server to authenticate users to OpenShift. Please refer to the LDAP Integration guide for using an LDAP server as an identity provider to govern user authentication to OpenShift. Client configuration file Connectivity Schema Group and User Queries Attribute Mapping Additional Configuration Options Explicit Group Mapping Executing the Synchronization job Whitelists/Blacklists Verifying Groups in OpenShift Associating Permissions to Synchronized Groups Pruning Groups References The OpenShift Container Platform contains a fully functional Role Based Access Control (RBAC) system.
This article proposes a reference architecture for a Highly Available installation of OpenShift. We will outline the architecture of such an installation and walk through the installation process. Cluster Design & Architecture Preparing the Installer Selecting the Version of OpenShift to Install Networking DNS SSL/TLS Certificates Load Balancing & HA Authentication Persistent Storage Design for Disconnected Environments Recap Building the Infrastructure Provision Servers Ansible Control Host Create Standalone Registry Sync RPM Channels Configure Load Balancer Preparing for Install Ansible Inventory Review Subscribing the Hosts Docker Storage Setup Configure etcd and Node Storage System Resource Reservations Validating Pre-requisites Running the Install Validating the Cluster What’s Next?
This is a followup to Installing a Highly Available OpenShift Cluster. Many assumptions are made based on the information in that guide. If you have not yet been through this guide, we recommend doing so before continuing. Overview How OpenShift Utilizes Certificates for Internal Communication Designing a Certificate Approach for OpenShift Configuring OpenShift to use Component-specific Custom Certificates Master API Certificate Default (Wildcard) Router Certificate Registry Certificate Other components Run Ansible Additional Resources What’s Next?