OpenShift In a Nutshell - Episode 04 - Infrastructure part II

Presentation By:
Behnam Loghmani
Summer 2016
IRAN OpenStack Users Group
OPENSHIFT
IN A NUTSHELL
(Episode 04)
Infrastructure (Cont.)

IRAN Community| OpenStack.ir
Agenda:
●
Nodes
●
Image Registry
●
Web Console
●
Iran OpenStack Community
OpenShift Infrastructure

Nodes

A node provides the runtime environments for containers. Each node in a Kubernetes
cluster has the required services to be managed by the master. Nodes also have the
required services to run pods, including Docker, a kubelet, and a service proxy.

OpenShift Origin creates nodes from a cloud provider, physical systems, or virtual
systems. Kubernetes interacts with node objects that are a representation of those
nodes. What this means is that when Kubernetes creates a node, it is really just creating
an object that represents the node in its internal state The master uses the
information from node objects to validate nodes with health checks. A node is ignored
until it passes the health checks, and the master continues checking nodes until they
are valid.

After creation, Kubernetes will check whether the node is valid or not. For example,
if you try to create a node from the following content:
{
  "kind": "Node",
  "apiVersion": "v1",
  "metadata": {
    "name": "10.240.79.157",
    "labels": {
      "name": "myfirstk8snode"
    }
  }
}

Kubernetes will create a Node object internally (the representation), and validate the
node by health checking based on the metadata.name field: we assume metadata.
name can be resolved. If the node is valid, i.e. all necessary services are running, it is
eligible to run a Pod; otherwise, it will be ignored for any cluster activity, until it
becomes valid. Note that Kubernetes will keep the object for the invalid node unless
it is explicitly deleted by the client, and it will keep checking to see if it becomes valid.

Administrators can manage nodes in an OpenShift Origin instance using the CLI. To
define full configuration and security options when launching node servers, use
dedicated node configuration files.

The recommended maximum number of nodes is 300.

apiVersion: v1
kind: Node
metadata:
  creationTimestamp: null
  labels:
    kubernetes.io/hostname: node1.example.com
  name: node1.example.com
spec:
  externalID: node1.example.com
Node Object Definition Example
1
2
3
4
5

apiVersion defines the API version to use.
kind set to Node identifies this as a definition for a node object.
metadata.labels lists any labels that have been added to the node.
metadata.name is a required value that defines the name of the node object. This
value is shown in the NAME column when running the oc get nodes command.
spec.externalID defines the fully-qualified domain name where the node can be
reached. Defaults to the metadata.name value when empty.
1
2
3
4
5
Node Object Definition Example (Cont.)

Each node has a kubelet that updates the node as specified by a container manifest,
which is a YAML file that describes a pod. The kubelet uses a set of manifests to ensure
that its containers are started and that they continue to run.
Kubelet

A container manifest can be provided to a kubelet by:
●
A file path on the command line that is checked every 20 seconds.
●
An HTTP endpoint passed on the command line that is checked every 20 seconds.
●
The kubelet watching an etcd server, such as /registry/hosts/$(hostname -f),
and acting on any changes.
●
The kubelet listening for HTTP and responding to a simple API to submit a new
manifest.
Kubelet (Cont.)

Each node also runs a simple network proxy that reflects the services defined in
the API on that node. This allows the node to do simple TCP and UDP stream
forwarding across a set of back ends.
Service Proxy

Image Registry

OpenShift Origin can utilize any server implementing the Docker registry API as a
source of images, including the canonical Docker Hub, private registries run by third
parties, and the integrated OpenShift Origin registry.

OpenShift Origin provides an integrated Docker registry that adds the ability to
provision new image repositories on the fly. This allows users to automatically have
a place for their builds to push the resulting images.
Whenever a new image is pushed to the integrated registry, the registry notifies
OpenShift Origin about the new image, passing along all the information about it,
such as the namespace, name, and image metadata. Different pieces of OpenShift
Origin react to new images, creating new builds and deployments.
Integrated OpenShift Origin Registry

OpenShift Origin can create containers using images from third party registries, but
it is unlikely that these registries offer the same image notification support as the
integrated OpenShift Origin registry. In this situation OpenShift Origin will fetch
tags from the remote registry upon imagestream creation. Refreshing the fetched
tags is as simple as running oc import-image <stream>. When new images are
detected, the previously-described build and deployment reactions occur
Third Party Registries

OpenShift Origin can communicate with registries to access private image repositories
using credentials supplied by the user. This allows OpenShift Origin to push and pull
images to and from private repositories.
Authentication

Web Console

The OpenShift Origin web console is a user interface accessible from a web browser.
Developers can use the web console to visualize, browse, and manage the contents of
projects.
The web console is started as part of the master. All static assets required to run the
web console are served from the openshift binary. Administrators can also customize
the web console using extensions, which let you run scripts and load custom
style sheets when the web console loads. You can change the look and feel of nearly
any aspect of the user interface in this way.

When you access the web console from a browser, it first loads all required static assets.
It then makes requests to the OpenShift Origin APIs using the values defined from the
openshift start option --public-master, or from the related master configuration file
parameter masterPublicURL. The web console uses WebSockets to maintain a persistent
connection with the API server and receive updated information as soon as it is available.

The configured host names and IP addresses for the web console are whitelisted to
access the API server safely even when the browser would consider the requests to be
cross-origin. To access the API server from a web application using a different host
name, you must whitelist that host name by specifying the --cors-allowed-origins
option on openshift start or from the related master configuration file parameter
corsAllowedOrigins.

Video Channels
https://www.youtube.com/behnamloghmani
http://www.aparat.com/behnamloghmani

OpenShift Architecture
Iran OpenStack Community

OpenShift Architecture
Stay in Touch and Join Us:
●
Home Page: OpenStack.ir
●
Meetup Page: Meetup.com/Iran-OpenStack
●
Mailing List: OpenStack-ir@Lists.OpenStack.org
●
Twitter: @OpenStackIR , #OpenStackIRAN
●
IRC Channel on FreeNode: #OpenStack-ir

Thank You
Behnam Loghmani
Iran OpenStack Community Member
Behnam.loghmani@gmail.com
OpenStack.ir
We need to work together to build a better community

OpenShift In a Nutshell - Episode 04 - Infrastructure part II

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to OpenShift In a Nutshell - Episode 04 - Infrastructure part II (20)

Recently uploaded (20)

OpenShift In a Nutshell - Episode 04 - Infrastructure part II