- Documentation
- OpenShift Container Platform
- Networking
- Understanding networking history
- About
- Release notes
- Architecture
- Installing
- Updating clusters
- Support
- Web console
- Authentication
- Understanding authentication
- Configuring the internal OAuth server
- Understanding identity provider configuration
- Configuring identity providers
- Configuring an HTPasswd identity provider
- Configuring a Keystone identity provider
- Configuring an LDAP identity provider
- Configuring a basic authentication identity provider
- Configuring a request header identity provider
- Configuring a GitHub or GitHub Enterprise identity provider
- Configuring a GitLab identity provider
- Configuring a Google identity provider
- Configuring an OpenID Connect identity provider
- Configuring certificates
- Using RBAC to define and apply permissions
- Removing the kubeadmin user
- Configuring the user agent
- Understanding and creating service accounts
- Using service accounts in applications
- Using a service account as an OAuth client
- Scoping tokens
- Managing Security Context Constraints
- Impersonating the system:admin user
- Syncing LDAP groups
- Networking
- Storage
- Understanding persistent storage
- Configuring persistent storage
- Persistent storage using AWS Elastic Block Store
- Persistent storage using Fibre Channel
- Persistent storage using NFS
- Persistent storage using hostPath
- Persistent Storage using iSCSI
- Persistent storage using Container Storage Interface (CSI)
- Persistent storage using VMware vSphere
- Persistent storage using volume snapshots
- Expanding persistent volumes
- Dynamic provisioning
- Registry
- Builds
- Understanding image builds
- Understanding build configurations
- Creating build inputs
- Managing build output
- Using build strategies
- Custom image builds with Buildah
- Performing basic builds
- Triggering and modifying builds
- Performing advanced builds
- Using Red Hat subscriptions in builds
- Securing builds by strategy
- Build configuration resources
- Troubleshooting builds
- Setting up additional trusted certificate authorities for builds
- Images
- Applications
- Machine management
- Nodes
- Working with pods
- Controlling pod placement onto nodes (scheduling)
- About pod placement using the scheduler
- Configuring the default scheduler to control pod placement
- Placing pods relative to other pods using pod affinity and anti-affinity rules
- Controlling pod placement on nodes using node affinity rules
- Placing pods onto overcommited nodes
- Controlling pod placement using node taints
- Placing pods on specific nodes using node selectors
- Using Jobs and DaemonSets
- Working with nodes
- Working with containers
- Using containers
- Using Init Containers to perform tasks before a pod is deployed
- Using volumes to persist container data
- Mapping volumes using projected volumes
- Allowing containers to consume API objects
- Copying files to or from a container
- Executing remote commands in a container
- Using port forwarding to access applications in a container
- Working with clusters
- Logging
- About cluster logging
- About deploying cluster logging
- Deploying cluster logging
- Viewing the Kibana interface
- Deploying and Configuring the Event Router
- Configuring your cluster logging deployment
- Viewing Elasticsearch status
- Moving the cluster logging resources with node selectors
- Manually rolling out Elasticsearch
- Troubleshooting Kibana
- Exported fields
- Uninstalling cluster logging
- Monitoring
- Telemetry
- Scalability and performance
- Backup and restore
- CLI reference
- Service Mesh
- Serverless applications
- Getting started with OpenShift Serverless
- OpenShift Serverless product architecture
- Installing OpenShift Serverless
- Getting started with Knative services
- Monitoring OpenShift Serverless components
- Cluster logging with OpenShift Serverless
- Configuring Knative Serving autoscaling
- Using Knative Client
- Release Notes
Understanding networking
Kubernetes ensures that Pods are able to network with each other, and allocates each Pod an IP address from an internal network. This ensures all containers within the Pod behave as if they were on the same host. Giving each Pod its own IP address means that Pods can be treated like physical hosts or virtual machines in terms of port allocation, networking, naming, service discovery, load balancing, application configuration, and migration.
OpenShift Container Platform DNS
If you are running multiple services, such as front-end and back-end services for use with multiple Pods, environment variables are created for user names, service IPs, and more so the front-end Pods can communicate with the back-end services. If the service is deleted and recreated, a new IP address can be assigned to the service, and requires the front-end Pods to be recreated to pick up the updated values for the service IP environment variable. Additionally, the back-end service must be created before any of the front-end Pods to ensure that the service IP is generated properly, and that it can be provided to the front-end Pods as an environment variable.
For this reason, OpenShift Container Platform has a built-in DNS so that the services can be reached by the service DNS as well as the service IP/port.