Transcript

POCKET DICTIONARY

And Container Orchestration

Editionst1

Introduction This glossary describes terms related to containers, container orchestration and cloud-native technologies with the focus on Kubernetes. We supplement Kubernetes terminology with important computing and programming terms that put container orchestration in context.

Container Orchestration

AAggregation Layer

The aggregation layer allows extending Kubernetes with additional APIs so that these APIs are available on the core Kubernetes API. The K8s aggregation layer will forward requests sent to the kube-apiserver to your application’s API if the requests hit API paths claimed by your application’s registered APIServices.

Annotation

In Kubernetes, an annotation is a key-value pair for attaching arbitrary structured or unstructured metadata to Kubernetes API objects. In contrast to labels, annotations are not designed to identify and select objects, although they are often used to convey important information to K8s resources and controllers or other applications.

Autoscaling

Autoscaling is an automatic adjustment of cluster/compute resources based on load. With this feature, the system increases resources when the load increases and vice versa. Horizontal autoscaling is increasing the number of instances whereas vertical autoscaling is increasing their size (see HPA and vertical autoscaling). Supergiant Capacity ships with a built-in autoscaling feature based on the cost-effective packing algorithm. It allows intelligent spin up and spin down of cluster nodes with resource requirements exactly matching the load.

CCgroup

The cgroup (control group) is a Linux kernel feature that allows allocating and limiting CPU time, system memory, network bandwidth, and other resources among processes on the system. By using cgroups, system administrators can achieve fine-grained control over system resources and distribute them efficiently among

Container Orchestration

processes. The cgroup is one of the cornerstones of the Linux container technology.

Cloud Service Provider

A Cloud provider (CSP) is a company that offers infrastructure and services for running containers and container orchestration tools. They can offer Infrastructure as a Service (IaaS) for deploying cluster nodes, Platform as a Service (PaaS) for managing applications, and a variety of storage and network services. Supergiant toolkit includes built-in support for major cloud providers including Google Compute Engine (GCE) and Amazon EC2.

Cluster

A cluster is three or more connected physical computers or virtual machines that constitute a single system. A worker machine in a cluster is referred to as a node or minion, and the leader of the cluster is normally referred to as master. When referring specifically to K8s, a cluster is one or more machines hosting the full set of K8s microservices which make up the K8s platform.

ConfigMap

A ConfigMap is a Kubernetes API primitive designed to store non-confidential data such as configuration in a read-only volume used by Pods. This primitive is useful for decoupling environment-specific configuration from containers. ConfigMaps can be consumed as environmental variables, configuration files in a volume, or command-line arguments.

Container

A container is a technology for packaging applications with their entire runtime environment (e.g., binaries, filesystem, dependencies) and isolating them from the host OS. Because of this self-contained design and flexibility, containers allow disentangling applications from the underlying infrastructure and isolating them from the host environment, thereby making them highly portable and environment-agnostic. This has accelerated a global adoption of distributed microservices and cloud computing. However, Containers do not contain all application concerns and can be less secure than VMs.

Container Orchestration

Popular container technologies include Docker, rkt, containerd, and more.

Containerized Application

A containerized application is an application that has been packaged to run in one or more containers.

Controller

In Kubernetes, a controller is an executable loop that observes the shared state of a cluster through the API server and intervenes to change the current state towards the desired state.

CNI (Container Network Interface)

CNI (Container Network Interface) is a CNCF (Cloud Native Computing Foundation) project that develops specifications and libraries for writing plugins to configure network interfaces for Linux containers. The main goal of the project is to define common interfaces between the network plugins and container execution. Kubernetes

supports CNI standards, which allows developers to use CNI-compliant network plugins on the platform.

CI/CD

CI/CD is a software engineering pipeline that includes a combination of Continuous Integration (CI) with Continuous Delivery (CD) or Continuous Development (CD). See the description of these terms below to find out more.

Continuous Delivery

Continuous Delivery is a software engineering approach for automating the software release process. It allows deploying the application at any point of time with no effort (e.g., by clicking a button). With continuous delivery, you can create releases daily, weekly, monthly, or on whatever schedule suits your business requirements.

Continuous Deployment

Continuous Deployment is the uniting of Continuous Integration with Continuous Delivery, automating the

Container Orchestration

whole pipeline from code commit to customer. It ensures that every change passing the stages of the software testing pipeline is automatically released to the software’s users.

Continuous Integration

Continuous Integration is a practice of automated incorporation of code changes to the upstream repository ensured by automated tests against the build. CI makes code updates much easier and helps de-link release cycle from the code changes. To achieve this, CI puts a great emphasis on testing automation to check that the application is not broken when new commits are integrated into the main branch.

Control Plane

Control Plane is a combination of Kubernetes master processes that track events in the cluster and work to make the current state of all objects in the cluster match the desired state set by the administrator. The control plane includes etcd, the kube-apiserver, the kube-

controller-manager, the kube-scheduler, and the cloud-controller-manager.

CNCF

The Cloud Native Computing Foundation (CNCF) is an open source project hosted by the Linux Foundation. CNFC hosts a number of important open source projects including Kubernetes, Prometheus, OpenTracing, Fluentd, and Linkerd. Supergiant is a silver member of CNCF and is a Kubernetes Certified Service Provider.

CronJob

CronJob is a sub-type of Kubernetes jobs that runs on a periodic schedule. The schedule is specified using the Cron format.

Container Orchestration

DDaemonSet

A DaemonSet is a Kubernetes resource that ensures that all (or some) nodes run a copy of a Pod. It is akin to a system daemon running on an OS except that a DaemonSet runs as a system daemon on a K8s cluster. A DaemonSet adds Pods to new nodes and garbage collects Pods as nodes are removed from the cluster. Deleting a DaemonSet will remove the Pods it created.

Deployment

The Kubernetes Deployment is an API primitive for deploying and managing ReplicaSets, which facilitate fault tolerance for Pods. For example, Deployments can inform ReplicaSets of how many Pods to have, as well as to what specification. Deployments also add extra functionality to ReplicaSets, such as rolling updates and rollbacks, making them more robust and more suitable for most needs than the ReplicaSet alone.

Desired State

Desired State means the state of a Kubernetes application(s), including number of replicas, container images, network, and resources available specified by the administrator. The desired state can be set and changed by creating objects using the Kubernetes declarative syntax. The desired state is enforced by the control plane (see Control Plane).

DevOps

DevOps is a set of computer engineering practices aimed at unifying the processes between software development (Dev) and IT teams (Ops) to improve development and operation of software and infrastructure. The main benefits of DevOps include increased trust and better communication and coordination between software departments, resulting in faster software releases, updates, and fixes, and the ability to resolve critical issues faster.

Docker

Docker is a computer program that executes OS-level

Container Orchestration

virtualization known as containers. Docker abstracts away the resource isolation and resource management functionality of the Linux kernel such as cgroups and kernel namespaces and allows independent “containers” to run within a single Linux instance, avoiding the expenses of booting and managing virtual machines (VMs).

Docker Swarm

Docker Swarm is a native clustering solution for Docker that turns a pool of Docker hosts into a single virtual Docker host. Because Docker Swarm serves the standard Docker API, any program that communicates with a Docker daemon can use Swarm to scale to multiple hosts.

Dynamic Volume Provisioning

DVP eliminates the need to pre-provision cluster storage by allowing Kubernetes users to request automatic creation of storage. It is based on an API primitive, StorageClass, referring to a volume plugin that provisions a volume and a set of parameters to pass to that volume plugin.

EEndpoint

In Kubernetes, an Endpoint is the API object that refers to a Pod managed by some Service. When users create a Service, a set of Endpoints with a corresponding list of IPs and ports are created targeting Pods that match the selector of the Service.

Etcd

Etcd is a reliable and highly-available key-value store used as Kubernetes’ backing store for all cluster data.

FFault Tolerance

Fault tolerance is the computing system property that enables a system to continue functioning properly in the event of the failure of some of its components.

Container Orchestration

Flannel

Flannel is a popular layer 3 overlay network solution for Kubernetes. Running on each host, Flannel is responsible for allocating a subnet lease to the host out of a larger address space. Flannel uses either the Kubernetes API or etcd directly to store the network configuration, the allocated subnets, and any supplementary data (such as the host's public IP). Although Flannel does not support NetworkPolicies, it can be used with Calico, which does (see Overlay).

Fluentd

Fluentd is a multi-purpose data collector with the support for shipping logs from multiple sources including NoSQL, RDBMS, IaaS, web servers, etc. It is one of the most popular logging solutions for Kubernetes, allowing creation of a unified logging infrastructure known as the Unified Logging Layer.

HHardware Virtualization

Hardware or platform virtualization allows creating virtual machines that emulate a specific operating system and run them on the machine hosting a different operating system. Software executed on these virtual machines is separated from the host’s hardware resources. For example, with hardware virtualization, you can run Windows on the machine hosting Linux operating system.

Helm Chart

A Helm chart is a package of pre-configured Kubernetes resources such as Deployments and ConfigMaps that can be deployed and managed by Tiller, an on-cluster agent for creating "releases" initiated via the Helm CLI. A single chart can be used to deploy standalone applications or complex web stacks with HTTP servers, caches, and databases. The main benefit of Helm charts is the simplification of the deployment and management of Kubernetes resources, facilitating repeatability and standardization of a team's resource configuration.

Container Orchestration

Supergiant ships with community-maintained and Supergiant-approved Helm charts that can be easily configured and deployed using Supergiant’s control plane.

Horizontal Pod Autoscaler

A Kubernetes API resource that automatically scales the number of Pod replicas depending on the targeted CPU utilization or other custom metrics. It can only be used with Deployments, ReplicaSets, and Replication Controllers.

IImage

In the context of container technology, an image is a stored instance of a container that holds software and configuration needed to run an application. Images are packaged and stored in a container registry and can be pulled locally to run an application. Images also include metadata indicating which executable to run, who built the image, and other useful information (see Registry).

Ingress

In Kubernetes, Ingress is an API primitive that manages a set of rules for external access to the services in a cluster (typically via HTTP). Ingress can also provide load balancing, SSL termination, and name-based virtual hosting.

Init Container

In Kubernetes, an initialization container is a container that must run to completion before the main app can run. Init containers are typically used to perform some initialization tasks such as downloading a remote repository, configuring the system’s environment, and other operations that need to be completed before the main application can run.

JJob

A Kubernetes Job is a special controller that can create

Container Orchestration

Pods and manage them in the process of doing some finite work. Jobs secure the Pod's successful completion and can reschedule Pods if they fail or terminate because of node hardware failure or node reboot. Kubernetes has a native support for parallel jobs for distributing workloads between multiple worker Pods or performing the same task multiple times until reaching the completions count.

KKubernetes

Kubernetes (or K8s) is an open source platform for the deployment and management of containerized applications at scale, originally developed by Google and open sourced in 2014. It is designed to automate and abstract many container administration needs (such as deployment, updates, and networking), through its set of unique primitives, such as Pods and Services. With Kubernetes, it is simple to group multiple hosts running containers, turning them into a “cluster” of machines under the authority of a control plane of intelligent microservices, which can manage your infrastructure's

desired state. K8s is highly configurable and embodies the philosophy of “cattle, not pets”.

kubeadm

kubeadm is an open source tool for fast installation of Kubernetes and setting up a secure cluster. It can be used to install both the control plane and the worker node components. kubeadm is also the foundation of many other provisioning tools, such as Kubicorn and Kops.

kubectl

kubectl is a command line tool used for communication with a Kubernetes API server. It allows creating, editing, updating, and deleting Kubernetes resources, as well as debugging and monitoring the health of the cluster, along with many other tasks.

kubelet

kubelet is a node agent in Kubernetes that runs on each node of the cluster and makes sure that containers are running in a Pod. A kubelet takes Pod specifications

Container Orchestration

also known as manifests and ensures that containers described in them are running and healthy.

Kubernetes API

Kubernetes API exposes Kubernetes functionality through a RESTful interface. All Kubernetes resources such as Deployments or DaemonSets are stored as API objects that can be modified via RESTful calls to the API. Users can interact with the API directly or via tools like kubectl. The core Kubernetes API is flexible and can be extended to support custom resources.

kube-apiserver

A control plane component that exposes the Kubernetes API, kube-apiserver is the front-end for the Kubernetes control plane. It also intermediates between other control plane components. Requests to the kube-apiserver undergo an admission pipeline from authentication (“are you allowed to talk to me?”) to authorization (“are you allowed to ask that of me?”) to admission (“is there anything else I need to do before admitting this?”). Once this pipeline is passed, requests may be executed. All

requests to the kube-apiserver must go through this pipeline (see Control Plane).

kube-controller-manager

Kube-controller-manager is a master component that runs controllers. The control loops include any logic not specific to the cloud provider used by the cluster (except volumes). If any cloud-provider-specific control loops (such as loops for routing, nodes, and other cloud infrastructure) are desired, they are handled by the optional cloud-controller-manager.

kube-proxy

Kube-proxy is a network proxy running on each node of the cluster and responsible for request forwarding. It allows TCP and UDP stream or round-robin forwarding across a set of backend functions. The kube-proxy achieves this through multiple, user-selected modes that behave in different ways. Kube-proxy may or may not do any forwarding of its own, based on the selected mode.

Container Orchestration

kube-scheduler Kube-scheduler is a master component that watches newly created Pods with no node assigned. The Scheduler informs the API Server of the appropriate node to schedule on, and then the API Server sends a request to the appropriate Kubelet to create the necessary Pods.

LLabel

In Kubernetes, labels are key/value pairs that are attached to objects such as Pods. They are used to create object attributes that are meaningful and relevant to users to help them organize and select subsets of objects. Labels are taken advantage of through the use of “selectors,” which match desired labels (see Selector).

MMaster

In computer networking, a master is a central machine that controls other machines in the cluster. In the context of Kubernetes, the “master” refers to a collection of processes managing the cluster state also known as the “control plane”. These processes can also be deployed in other patterns, such as outside the cluster, inside the worker nodes, or even in another separate cluster. The master can be replicated for availability and redundancy.

Microservice

Microservices or microservice architecture is a design approach that structures an application as a group of small, discrete, loosely coupled, goal-oriented services which implement business capabilities. They facilitate DevOps culture and CI/CD pipelines and simplify delivery/deployment of large, complex applications where each component can be independently developed, tested, deployed, and scaled.

Container Orchestration

Minikube

A tool for running single-node Kubernetes clusters locally, Minikube uses a virtual machine to host a cluster with both the control plane services (kube-apiserver, controller-manager, etc.) and node services (container runtime, kubelet, etc.), often used for development and testing.

NNamespace

Namespace is a Kubernetes abstraction that allows creating multiple logical workspaces within one cluster (for example, “kube-system” and “default”). Namespaces can be used to organize objects in a cluster, and provide a way to divide cluster resources between teams and users.

Network Policy

By default, all Pods can communicate with all other Pods. In Kubernetes, a network policy specifies how groups of Pods are allowed to communicate with each

other and with other network endpoints. They help users declaratively configure which Pods are allowed to connect to each other, which namespaces are allowed to communicate, and which port numbers to enforce each policy on.

Node

A worker machine in the Kubernetes cluster that may be a virtual or physical machine depending on the cluster’s deployment pattern. A node runs user applications and cloud workflows and is managed by the master components (such as kube-scheduler). The services on each node include Docker or another container runtime, kubelet, and kube-proxy.

NodePort

A Kubernetes networking feature for exposing a service on each Node’s IP at a static port known as NodePort. NodePort enables communication with the Kubernetes service from the outside of the cluster via NodeIP:NodePort.

Container Orchestration

OOCI—Open Container Initiative

The Open Container Initiative (OCI) is an open-governance structure for developing open industry standards around container formats and runtime. Established in June 2015, the OCI currently contains two specifications: the Runtime Specification (runtime-spec) and the Image Specification (image-spec). The Runtime Specification describes how to run a “filesystem bundle” that is unpacked on disk. The Image Specification outlines the process of downloading and unpacking OCI images into an OCI Runtime filesystem bundle.

OpenTracing

Tracing is the art of gaining insight into requests and processes as they move through distributed, and often complex, systems, which contributes to the debugging and monitoring of such systems. OpenTracing is a vendor-neutral standard for distributed tracing hosted by CNCF. Other open-source alternatives include Jaeger or service meshes such as Linkerd2 or Istio.

Orchestration

In the container context, an orchestration is a process and a set of tools for managing the life cycles of containers, especially in large dynamic environments. Software teams use container orchestration to control and automate many tasks, including provisioning and deployment of containers, redundancy, and availability of containers, scaling, updating, scheduling, and more. Supergiant simplifies common Kubernetes administration tasks. Just as Kubernetes orchestrates containers, Supergiant offers a little bit of orchestration for Kubernetes.

Overlay Network

An overlay network is a software-defined networking component that rides on top of the underlay and provides networking such as IP addresses and ports, for the lifecycle of containers and hosts. The overlay can isolate communication between applications that use the same physical network. Overlay technologies include Flannel, Calico etc.

Container Orchestration

OS-level Virtualization

Operating system-level virtualization, also known as containerization, is an OS feature in which the kernel allows the existence of multiple isolated user-space instances. Various types of these instances such as containers, partitions, jails (FreeBSD) may look like a real computer from the point of view of programs running in them. However, programs running inside a container can see only the container's contents and devices assigned to the container. They cannot see or access all resources of OS that hosts them.

PPod

A Pod Security Policy is a cluster-level resource that defines a set of security conditions for a Pod to run with in order to be approved by the system. PSPs restrict a Pod's security context, which can close critical holes in cluster security (which many container runtimes do not natively

address). This resource is implemented as an optional admission controller.

Pod Security Policy

A Pod Security Policy is a cluster-level resource that defines a set of security conditions for a Pod to run with in order to be approved by the system. PSPs restrict a Pod's security context, which can close critical holes in cluster security (which many container runtimes do not natively address). This resource is implemented as an optional admission controller.

Prometheus

Prometheus is an open source monitoring and alerting toolkit that was developed by SoundCloud in 2012. Prometheus is now tightly integrated into the ecosystem and has native support for containers and Kubernetes.

Container Orchestration

RRBAC (Role-Based Access Control)

In Kubernetes, RBAC is a set of resources that allows admins to dynamically configure access policies for objects running on the cluster. RBAC works by taking a set of subjects (users, groups, or ServiceAccounts), a set of rules (Roles or ClusterRoles), and binding them together (RoleBindings or ClusterRoleBindings). RBAC is designed to improve authorization, the second stage of the admission pipeline (see kube-apiserver).

Registry

A container registry is a hosted repository of container images. It is a single place for your team to manage container images, perform vulnerability analysis, and enable RBAC for image access. There exist private registries overseen by companies and public container registries such as Docker Hub, Quay or GCR.

ReplicaSet

ReplicaSet is the next-generation ReplicationController for ensuring that a specified number of Pods replicas is running at one time. It achieves this through providing a template for Pods to be molded to upon creation and by utilizing the controller-manager to keep Pod state enforced so users no longer need to be manually involved in maintaining running clones of their containers. This also introduces the scaling of Pods to administrators, as well as automated resource updates across replicas, although they still require direct administration (see Deployment).

Resource Quotas

Resources quotas are Kubernetes resource constraints that limit aggregate resource consumption per namespace. They can be used to limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that namespace.

Container Orchestration

rkt

rkt is an application container engine based on the Pod-native approach developed for modern production cloud-native environments. In addition to native support for running Docker containers, rkt includes robust default security features, although Kubernetes can provide such security when configured to do so. It was introduced by CoreOS in December 2014. (CoreOS was subsequently acquired by Red Hat, which was then acquired by IBM in 2018).

Runtime

In general computing, “runtime” is either the lifecycle phase when a program is running or the framework that supports its execution. In terms of containers, a runtime like Docker is akin to the hypervisor of a VM, but instead of translating between one OS and another, container processes are executed directly in the host kernel. (However, this requires that the container “OS” or contents be similar to the host OS.) The runtime is responsible for

all the parts of running a container except the contained process. K8s can use more than one container runtime on a node if needed.

SSelector

A selector is a Kubernetes feature that allows users or other K8s resources to filter a list of resources based on labels. Selectors are to labels as dialing pads are to phone calls. They are the means by which labels in K8s are implemented.

Service

A Kubernetes API primitive that describes how to access applications, such as a set of Pods. Services act as load-balancers that link frontend application with a set of backend Pods. Specifically speaking, newly created Services inform kube-proxy to create new networking rules, which then allow Pods to communicate.

Container Orchestration

Service Account

In terms of RBAC, ServiceAccounts are like the “user” equivalent for services running in the cluster. Just as human users need to be authorized, so do services. ServiceAccounts provide services with identities they can use for authorization.

Service Discovery

In a situation of non-static backends with changing IPs, a service discovery detects the dynamically assigned networking information of the services or the devices on which they are running.

Service Mesh

A service mesh is a management layer for a microservices application. Its basic purpose is to improve cluster administration. Service meshes provide a number of services like load balancing, service discovery, authentication and authorization, circuit breakers, monitoring, tracing, and more, although each additional service increases the skill level required to properly operate

the mesh. A service mesh is usually implemented by providing a proxy instance (a sidecar) for each service instance and a set of control plane components.

StatefulSet

Similarly to Deployments, a StatefulSet allows managing a set of Pods based on an identical container spec. In contrast to Deployments, however, a StatefulSet maintains a sticky identity for its Pods. Each Pod in a StatefulSet gets a persistent identifier (UID), sticky sub-domain, and a CRV record maintained across any rescheduling and restart. These features make StatefulSets useful for applications where preserving a Pod's exact state is critical.

Sunset Service

A sunset service allows painless and efficient destruction and re-creation of applications, especially stateful ones (e.g., databases). Sunset services secure the integrity of storage, caches, security, and other components of state during the application restart or migration.

Container Orchestration

UUID

A UID (sometimes also referred to as UUID) is a Kubernetes systems-generated string to uniquely identify objects. In addition to providing an identity to K8s resources, it is also used all around the world as a general standard for tagging software and hardware resources, from users to cars, and the standard is designed to reduce the likelihood of a the same UID being generated more than once.

VVertical Autoscaling

Vertical autoscaling means automatic adjustments of CPU and RAM resources of your cluster so your application runs at peak performance. The concept is split into two categories: (1) vertical autoscaling of nodes and (2) vertical autoscaling of Pods. Vertical node autoscaling is adding CPU and RAM resources to a node. Correspondingly,

vertical Pod autoscaling ensures that running Pods always have resource requests and limits that accurately reflect their containers' actual usage, avoiding over-provisioning of resources or a crash from having inadequate resources allocated to a container.

Volume

A Kubernetes volume is a directory containing data, accessible to the containers in a Pod. A volume lives as long as the Pod that encloses it. Consequently, a volume allows preserving data across container restarts. If the volume is created externally by a program or admin, such as an AWS EBS volume, it will live beyond the death of the Pod via being unmounted instead of deleted.

Container Orchestration

YYAML

YAML (YAML Ain’t Markup Language, formerly known as Yet Another Markup Language) is a human-readable data serialization language commonly used for configuration files (although not limited to them). In Kubernetes, specification files can be written in YAML or JSON. All requests sent directly to the Kubernetes API must use JSON, and kubectl will convert YAML to JSON upon submission of the manifest.

Supergiant (SG) is a toolkit that empowers developers and administrators through simplified deployment and management of Kubernetes. It enables and facilitates clusters on multiple cloud providers, provides a cost-effective and efficient autoscaling system based on resource utilization, brings a powerful recommendation engine, and presents other useful features.

SG consists of several micro-services that can work both as a single force and separately. Each part of the toolkit contributes to the overall goal of making Kubernetes approachable enough and “complete” enough for users from developers to enterprises.

Supergiant components are:

Visit: supergiant.io/toolkit

control

capacity

analyze

Supergiant Toolkit

Control is the “Mothership” or central hub through which all tools can be plugged in and controlled. Control manages cloud accounts, provisioning and lifecycle of clusters on your infrastructure, and it allows Deployment of applications via HELM. Its Deployment and configuration workflows will help you to get up and running with Kubernetes faster.

control

Supergiant Toolkit

Using Supergiant’s cost-effective packing algorithm, Capacity ensures that the right hardware is available for the required resource load of your Kubernetes cluster at any given time. This helps prevent over-provisioning of your container environment and overspending on your hardware budget without risking downtime.

capacity

Supergiant Toolkit

Analyze provides feedback on workload resources and makes recommendations for optimizing your utilization — and thereby getting the best return on your hardware investment.

After all, scaling down at the right time is just as important as scaling up… right?

analyze

©2018. Supergiant is a trademark of Qbox, Inc.

Kubernetes, Prometheus, and Helm are trademarks of Cloud Native Computing Foundation


Top Related