Skip to main content

The OpenShift Architecture

  • Chapter
  • First Online:
Architecting and Operating OpenShift Clusters

Abstract

To properly architect an OpenShift cluster, we need to understand the different components of the platform, their roles, and how they interact with each other. This base knowledge is important to be able to fine-tune OpenShift cluster design to your organization’s need beyond what is covered in this book.

This is a preview of subscription content, log in via an institution to check access.

Access this chapter

Chapter
USD 29.95
Price excludes VAT (USA)
  • Available as PDF
  • Read on any device
  • Instant download
  • Own it forever
eBook
USD 59.99
Price excludes VAT (USA)
  • Available as EPUB and PDF
  • Read on any device
  • Instant download
  • Own it forever
Softcover Book
USD 79.99
Price excludes VAT (USA)
  • Compact, lightweight edition
  • Dispatched in 3 to 5 business days
  • Free shipping worldwide - see info

Tax calculation will be finalised at checkout

Purchases are for personal use only

Institutional subscriptions

Notes

  1. 1.

    In some documentation, you may find a statement about the existence of six namespaces, and in other documentations, you will find seven namespaces listed. Those lists do not count the cgroup namespace which virtualizes the cgroup capabilities as a namespace. For details about the namespace vs. the capability, refer to the Linux man page cgroup_namespaces, the Linux man page for cgroups, and the Linux man page for namespaces.

  2. 2.

    The CRI specification defines four actions: CreatePod, StartPod, StopPod, and RemovePod.

  3. 3.

    For more details, visit https://github.com/prometheus/node_exporter

  4. 4.

    For more details, visit https://github.com/kubernetes/node-problem-detector

  5. 5.

    When using NodePorts, the requested or dynamically assigned port is allocated in all the nodes of the particular cluster. Additional details are available at https://kubernetes.io/docs/concepts/services-networking/service/#nodeport

  6. 6.

    In general the use of HostPort is discouraged. Acceptable use cases are DaemonSets or some networking services. Upstream HostPort documentation is scarce, but functionality is similar to NodePorts but for a subset of Nodes.

  7. 7.

    Kubernetes Ingress feature state: https://kubernetes.io/docs/concepts/services-networking/ingress/#prerequisites

  8. 8.

    OpenShift Routes: https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html

  9. 9.

    Reference https://blog.openshift.com/kubernetes-ingress-vs-openshift-route/

  10. 10.

    For information about build strategies, visit https://docs.openshift.com/container-platform/3.11/architecture/core_concepts/builds_and_image_streams.html

  11. 11.

    Source-to-Image (S2I) is an Open Source project ( https://github.com/openshift/source-to-image ) to create container images from source code. For information on how to use S2I in OpenShift, refer to https://docs.openshift.com/container-platform/3.11/creating_images/s2i.html

Author information

Authors and Affiliations

Authors

Rights and permissions

Reprints and permissions

Copyright information

© 2019 William Caban

About this chapter

Check for updates. Verify currency and authenticity via CrossMark

Cite this chapter

Caban, W. (2019). The OpenShift Architecture. In: Architecting and Operating OpenShift Clusters. Apress, Berkeley, CA. https://doi.org/10.1007/978-1-4842-4985-7_1

Download citation

Publish with us

Policies and ethics