3.1 Basic concepts

This page introduces the most important terms in OpenShift and Kubernetes. These terms are necessary to getting started with software development. More terms can be found here.

In OpenShift and Kubernetes telecommunication between pods are implemented in a way that should be understood. The communications behave differently from for example Docker Compose- or Docker Swarm environments.

More information from the following links:

• https://kubernetes.io/docs/concepts/
• https://kubernetes.io/docs/concepts/workloads/pods/

Pod

In Kubernetes, all containers are ran in Pods. A Pod is the smallest unit that Kubernetes controls as a unit. A single pod contains one or more containers. Each pod has a unique ip-address in the Kubernetes-cluster from the 10.* -network. In the case of Tike OpenShift,  pod IP-adresses are in 10.12.0.0/14 network.

The following are the most important qualities of pods. Here the word "node" means a singular underlying virtual machine in the OpenShift system.

• All containers in a Pod share localhost, gate space and possible PersistentVolumeClaims.
• A singular pod always exists on a singular node. All containers in a Pod are on the same node.
  • To make the project more fault tolerant, scaling multiple replicas of pods is advisable. An affinity setting for replicas should also be used, so that copies are ran on different nodes.
    
• Usually a single container is ran inside a pod, but in some special cases running a pod with multiple containers is recommended.
• Scaling an application is done by increasing the amount of pods, not by running more containers in a single pod.

Even though it is possible to create pods manually, this is not usually recommended. Developers and project administrators should create Deployment-, DeploymentConfig-, CronJob-, Job- or StatefulSet -objects, which in turn create pods. If a "bare" pod is created, Openshift will not make sure that the pod is restarted when necessary. Separate pods should only be used for interactive debugging.

It is not possible to access a Pod with it's IP-address from outside the cluster. Within the cluster directly accessing a pod is both difficult and not worth it, because:

• Pods are temporary. Virtual machines running the pods can be restarted. The process in a container can crash, and therefore containers in a Pod can crash. In both cases, OpenShift fixes the situation by restarting pods (possibly on a different virtual machine or node).
• Pods have random part in their names to avoid name conflicts.
  
  • → Referencing a Pod by name is very hard.
  • → The existence of a Pod, its name tai IP-address can not be trusted.

Service

Because Pods can not be directly accessed, Kubernetes offers the Service object. It is an abstraction, with which a permanent, named resource is created inside a cluster. With a Service, a Pod or a group of pods can be referenced.

• All Services also have their own IP-addressesin the 172.30.0.0/16 space.

Pods can have a label e.g "app=my_cool_application". With a Pod's labels and a Service's selector, a Service can direct traffic to the right pods.

• https://kubernetes.io/docs/concepts/services-networking/service/
• https://kubernetes.io/docs/tutorials/kubernetes-basics/expose/expose-intro/

Route AND ingress

A Route is Openshifts feature with which a project can offer their application to an external IP-address/url. A Route is targeted to a Service, which directs the traffic to the correct pods. The Route also defines how HTTPS is decoded. On the Kubernetes side of things, an Ingress is used instead of a Route. Creating or editing an Ingress is however a cluster wide operation, so in OpenShift a single project cannot edit Ingresses directly.

• A Route works by registering itself to the Ingress inside the cluster.
  • Tike clusters have two Ingresses, and on a firewall level one is limited to internal and peripheral network and the other is open to the entire internet.
  • In defining a Route, project developers can choose for themselves which ingress the Route should be tied to. This also functions as the choice for who the application should be accessible by, everyone or only people in helsinki.fi network.
  • You can also give an annotation, a list of specific IP addresses and/or CIDR ranges that acts as an allowlist,blocking other source IPs away, including those that would otherwise be allowed by Ingress firewall rules. This does not affect the blocks at those firewalls however, so internal and peripheral network ingress will still block global internet even if you include an address from that space in your annotation. The list also has maximum length of 61 addresses or CIDRs. More information: https://docs.openshift.com/container-platform/4.12/networking/routes/route-configuration.html → haproxy.router.openshift.io/ip_whitelist
• More instructions: 3.7 How to publish my application to the internet?