Contents

Container....................................................................................................................................1
Container Orchestration............................................................................................................3
Kubernetes: the gold standard..................................................................................................3
Other orchestration tools.......................................................................................................4
Kubernetes Cluster.................................................................................................................4
Namespace.............................................................................................................................5
Ingress........................................................................................................................................6

Container

CONTAINERS
Containers are an abstraction at the app layer that packages code and dependencies
together. Multiple containers can run on the same machine and share the OS kernel with
other containers, each running as isolated processes in user space. Containers take up less
space than VMs (container images are typically tens of MBs in size), can handle more
applications and require fewer VMs and Operating systems.
  A container is a standard unit of software that packages up code and all its
dependencies so the application runs quickly and reliably from one computing
environment to another.
 A Docker container image is a lightweight, standalone, executable package of
software that includes everything needed to run an application: code, runtime,
system tools, system libraries and settings.
 Container images become containers at runtime and in the case of Docker
containers - images become containers when they run on Docker Engine.
 Containerized software will always run the same, regardless of the infrastructure.
Containers isolate software from its environment and ensure that it works uniformly
despite differences for instance between development and staging.
 It leveraged existing computing concepts around containers and specifically in the
Linux world, primitives known as cgroups and namespaces. Docker's technology is
unique because it focuses on the requirements of developers and systems operators
to separate application dependencies from infrastructure.

VIRTUAL MACHINES
Virtual machines (VMs) are an abstraction of physical hardware turning one server into
many servers. The hypervisor allows multiple VMs to run on a single machine. Each VM
includes a full copy of an operating system, the application, necessary binaries and libraries -
taking up tens of GBs. VMs can also be slow to boot.

Container Orchestration
 Automating the deployment, management, scaling, networking, and availability of
your containers.
 Container orchestration is all about managing the lifecycles of containers, especially
in large, dynamic environments. Software teams use container orchestration to
control and automate many tasks:

o Provisioning and deployment of containers

o Redundancy and availability of containers
o Scaling up or removing containers to spread application load evenly across
host infrastructure
o Movement of containers from one host to another if there is a shortage of
resources in a host, or if a host dies
o Allocation of resources between containers
o External exposure of services running in a container with the outside world
o Load balancing of service discovery between containers
o Health monitoring of containers and hosts
o Configuration of an application in relation to the containers running it
 When you use a container orchestration tool, like Kubernetes or Docker Swarm, you
typically describe the configuration of your application in a YAML or JSON file,
depending on the orchestration tool.
 These configurations files (for example, docker-compose.yml) are where you tell the
orchestration tool where to gather container images (for example, from Docker
Hub), how to establish networking between containers, how to mount storage
volumes, and where to store logs for that container.
 Containers are deployed onto hosts, usually in replicated groups. When it’s time to
deploy a new container into a cluster, the container orchestration tool schedules the
deployment and looks for the most appropriate host to place the container based on
predefined constraints (for example, CPU or memory availability). You can even
place containers according to labels or metadata, or according to their proximity in
relation to other hosts—all kinds of constraints can be used.
 The beauty of container orchestration tools is that you can use them in any
environment in which you can run containers.

Kubernetes: the gold standard

 Originally developed by Google
 De facto standard for container orchestration
  Popular with DevOps practitioners because it allows them to deliver a self-service
Platform-as-a-Service (PaaS) that creates a hardware layer abstraction for
development teams.
 Extremely portable: It runs on Amazon Web Services (AWS), Microsoft Azure, the
Google Cloud Platform (GCP), or in on-premise installations.
 You can move workloads without having to redesign your applications or completely
rethink your infrastructure—which helps you to standardize on a platform and avoid
vendor lock-in.
The main architecture components of Kubernetes include:
Cluster. A cluster is a set of nodes with at least one master node and several worker nodes
(sometimes referred to minions) that can be virtual or physical machines.
Kubernetes master. The master manages the scheduling and deployment of application
instances across nodes, and the full set of services the master node runs is known as the
control plane. The master communicates with nodes through the Kubernetes API server. The
scheduler assigns nodes to pods (one or more containers) depending on the resource and
policy constraints you’ve defined.
Kubelet. (process) Each Kubernetes node runs an agent process called a kubelet that’s
responsible for managing the state of the node: starting, stopping, and maintaining
application containers based on instructions from the control plane. A kubelet receives all of
its information from the Kubernetes API server.
Pods. (collection) The basic scheduling unit, which consists of one or more containers
guaranteed to be co-located on the host machine and able to share resources. Each pod is
assigned a unique IP address within the cluster, allowing the application to use ports
without conflict. You describe the desired state of the containers in a pod through a YAML
or JSON object called a PodSpec. These objects are passed to the kubelet through the API
server.
Deployments, replicas, and ReplicaSets. A deployment is a YAML object that defines the
pods and the number of container instances, called replicas, for each pod. You define the
number of replicas you want to have running in the cluster via a ReplicaSet, which is part of
the deployment object. So, for example, if a node running a pod dies, the replica set will
ensure that another pod is scheduled on another available node.

Other orchestration tools

 Docker Swarm: a hardy bit player
 Apache Mesos (and Marathon): complex but flexible

Kubernetes Cluster
A Kubernetes cluster is a set of node machines for running containerized applications. If
you’re running Kubernetes, you’re running a cluster.

 At a minimum, a cluster contains a worker node and a master node. The master
node is responsible for maintaining the desired state of the cluster, such as which
 applications are running and which container images they use. Worker nodes
actually run the applications and workloads.
 Master node: The machine that controls Kubernetes nodes. This is where all task
assignments originate.
 Worker nodes: These machines perform the requested, assigned tasks. The
Kubernetes master controls them.
 Pod: A set of 1 or more containers deployed to a single node. A pod is the smallest
and simplest Kubernetes object.
 Service: A way to expose an application running on a set of pods as a network
service. This decouples work definitions from the pods.
 Volume: A directory containing data, accessible to the containers in a pod. A
Kubernetes volume has the same lifetime as the pod that encloses it. A volume
outlives any containers that run within the pod, and data is preserved when a
container restarts.
 Namespace: A virtual cluster. Namespaces allow Kubernetes to manage multiple
clusters (for multiple teams or projects) within the same physical cluster.

Namespace
Namespace provides an additional qualification to a resource name. This is helpful when
multiple teams are using the same cluster and there is a potential of name collision. It can
be as a virtual wall between multiple clusters.
(Like a class)
Functionality of Namespace:
Following are some of the important functionalities of a Namespace in Kubernetes:

 Namespaces help pod-to-pod communication using the same namespace.

 Namespaces are virtual clusters that can sit on top of the same physical cluster.
 They provide logical separation between the teams and their environments.
Resource Quota

 When several users or teams share a cluster with a fixed number of nodes, there is a
concern that one team could use more than its fair share of resources. Resource
quotas are a tool for administrators to address this concern.
 Provides constraints that limit aggregate resource consumption per namespace. It
can 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 project.
Persistent Volume

 The PersistentVolume subsystem provides an API for users and administrators that
abstracts details of how storage is provided from how it is consumed. To do this, we
introduce two new API resources: PersistentVolume and PersistentVolumeClaim.
  A PersistentVolume (PV) is a piece of storage in the cluster that has been provisioned
by an administrator or dynamically provisioned using Storage Classes. It is a resource
in the cluster just like a node is a cluster resource. PVs are volume plugins like
Volumes, but have a lifecycle independent of any individual Pod that uses the PV.
This API object captures the details of the implementation of the storage, be that
NFS, iSCSI, or a cloud-provider-specific storage system.
 A PersistentVolumeClaim (PVC) is a request for storage by a user. It is similar to a
Pod. Pods consume node resources and PVCs consume PV resources. Pods can
request specific levels of resources (CPU and Memory). Claims can request specific
size and access modes (e.g., they can be mounted once read/write or many times
read-only).
 PVs are resources in the cluster. PVCs are requests for those resources and also act as
claim checks to the resource.

Ingress
 An API object that manages external access to the services in a cluster, typically
HTTP.
 Ingress may provide load balancing, SSL termination and name-based virtual hosting.
 Edge router: A router that enforces the firewall policy for your cluster. This could be
a gateway managed by a cloud provider or a physical piece of hardware.
 Cluster network: A set of links, logical or physical, that facilitate communication
within a cluster according to the Kubernetes networking model.
 Service: A Kubernetes Service that identifies a set of Pods using label selectors.
Unless mentioned otherwise, Services are assumed to have virtual IPs only routable
within the cluster network.
 Ingress exposes HTTP and HTTPS routes from outside the cluster to services within
the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

kubectl apply Creates and Updates Resources through local or remote files.
GitLab is a web-based DevOps lifecycle tool that provides a Git-repository manager
providing wiki, issue-tracking and continuous integration/continuous deployment pipeline
features, using an open-source license, developed by GitLab Inc.
A CI/CD Pipeline implementation, or Continuous Integration/Continuous Deployment, is the
backbone of the modern DevOps environment. It bridges the gap between development
and operations teams by automating the building, testing, and deployment of applications.
AIMRM?
AWS Sagemaker
Amazon SageMaker is a fully managed service that provides every developer and data
scientist with the ability to build, train, and deploy machine learning (ML) models quickly.
SageMaker removes the heavy lifting from each step of the machine learning process to
make it easier to develop high quality models.

https://towardsdatascience.com/why-do-we-need-aws-sagemaker-79bce465f19f