OpenShift Concepts TODEPLETE: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
Line 105: Line 105:
==User Accounts==
==User Accounts==


Are created upon login or via the [[#API|API]].
Are created upon login or via the [[#API|API]] and represented with the <tt>User</tt> object.


==Service Accounts==
==Service Accounts==

Revision as of 23:12, 29 April 2017

Internal

Overview

OpenShift is supported anywhere RHEL is: bare metal, virtualized infrastructure (Red Hat Virtualization, vSphere, Hyper-V), OpenStack platform, public cloud providers (Amazon, Google, Azure). It runs on RHEL and Red Hat Atomic.

OpenShift Hosts

Master

A master is a RHEL or Red Hat Atomic host that orchestrates and schedules resources. It maintains the state of the OpenShift environment. Multiple masters can be present to insure HA.

The master provides the single API all tooling clients must interact with.

The access is protected via fine-grained role-based access control (RBAC).

The master monitors application health via user-defined pod probes. It handles restarting pods that failed probes automatically. Pods that fail too often are marked as "failing" and are temporarily not restarted. The OpenShift service layer sends traffic only to healthy pods.

Node

A node is a RHEL or Red Hat Atomic Host where applications run inside containers. Nodes are orchestrated by masters. The node daemon runs on node.

Container

All application instances run inside containers on the nodes. For more details, see Docker Containers.

The node Daemon

Pod

Kubernetes Pods

Pod Probe

Users can configure pod probes for liveness or readiness.

Storage

Volume

Kubernetes Volume

etcd

Kubernetes etcd

Scheduler

Kubernetes Scheduler

Docker Registry

OpenShift contains an integrated Docker registry. Users push images into registry and whenever a new image is stored in the registry, the registry notifies OpenShift about it and passes along image information such as the namespace, the name and the image metadata.

Service

Kubernetes Service

Routing Layer

The routing layer cooperates with the service layer. It runs in pods and it provides automated load balancing to pods, and routing around unhealthy pods. The routing layer is pluggable and extensible.

API

Kubernetes API

Label

Kubernetes Label

Selector

Kubernetes Selector

Replication Controller

Kubernetes Replication Controller

Networking

Router

The router component routes external requests to applications inside the OpenShift environment. The router is the ingress point for all traffic destined for OpenShift services. Runs in a container.

Route

A route is a way to expose a service by giving it an externally reachable hostname. A route is a mapping of an FQDN and path to the endpoints of a service. Each route consist of a route name, a service selector and an optional security configuration.

Projects

Projects allows groups of users to work together, define ownership of resources and manage resources. The project restricts and tracks use of resources with quotas and limits. A project is a Kubernetes namespace with additional annotations.

Kubernetes Namespaces

A project lets a community of users to organize and manage their content in isolation from other communities.

Each project has its own set of:

Objects

The objects include pods, services, replication controllers, etc.

User Accounts

Are created upon login or via the API and represented with the User object.

Service Accounts

Non-human users that act automatically with designated access to objects in their projects or other projects.

Group

Policies

Policies

Constraints

Constraints are quotas for each kind of object that can be limited.