JPA with Hibernate 3.
0 The Persistence Life Cycle
Instructor Notes:
Page 02-1
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Add instructor notes
here.
Page 02-2
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Add instructor notes
here.
Page 02-3
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
-When you deploy Kubernetes, you get a cluster.
-A Kubernetes cluster consists of a set of worker machines, called nodes, that
run containerized applications.
-Every cluster has at least one worker node.
-The worker node(s) host the Pods that are the components of the application
workload.
-The control plane manages the worker nodes and the Pods in the cluster.
-In production environments, the control plane usually runs across multiple
computers and a cluster usually runs multiple nodes, providing fault-tolerance
and high availability.
Page 02-4
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
-[Master]-Control Plane Components - The control plane's components make global decisions about the cluster (for example,
scheduling),
as well as detecting and responding to cluster events (for example, starting up a new pod when a deployment's replicas field is
unsatisfied).
Control plane components can be run on any machine in the cluster. However, for simplicity, set up scripts typically start all
control plane components on the same machine, and do not run user containers on this machine.
-kube-apiserver-The API server is a component of the Kubernetes control plane that exposes the Kubernetes API. The API
server is the front end for the Kubernetes control plane.The main implementation of a Kubernetes API server is kube-apiserver.
kube-apiserver is designed to scale horizontally—that is, it scales by deploying more instances. You can run several instances of
kube-apiserver and balance traffic between those instances.
-etcd-Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data.
If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for those data.
-kube-scheduler
Control plane component that watches for newly created Pods with no assigned node, and selects a
node for them to run on.
Factors taken into account for scheduling decisions include: individual and collective resource
requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality,
inter-workload interference, and deadlines.
-kube-controller-manager- Control Plane component that runs controller processes.
Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a
single binary and run in a single process.
These controllers include:
Node controller: Responsible for noticing and responding when nodes go
down.
Replication controller: Responsible for maintaining the correct number of
pods for every replication controller object in the system.
Endpoints controller: Populates the Endpoints object (that is, joins Services
& Pods).
Service Account & Token controllers: Create default accounts and API
access tokens for new namespaces.
-cloud-controller-manager-A Kubernetes control plane component that embeds cloud-specific control logic.
The cloud controller manager lets you link your cluster into
your cloud provider's API, and separates out the components that interact with that cloud platform from
components that
just interact with your cluster. The cloud-controller-manager only runs controllers that are specific to
your cloud provider.
If you are running Kubernetes on your own premises, or in a learning environment inside your own PC,
the cluster does not have a cloud controller manager.
As with the kube-controller-manager, the cloud-controller-manager combines several logically
independent control loops into a single binary that you run as a single process. You can scale horizontally
(run more than one copy) to improve performance or to help tolerate failures.
The following controllers can have cloud provider dependencies:
Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud
after it stops responding
Route controller: For setting up routes in the underlying cloud infrastructure
Service controller: For creating, updating and deleting cloud provider load balancers
Page 02-5
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
• Kubernetes has a decentralized architecture that does not handle tasks
sequentially
• It functions based on a declarative model and implements the concept of a
‘desired state.’ These steps illustrate the basic Kubernetes process:
• An administrator creates and places the desired state of an application into
a manifest file.
• The file is provided to the Kubernetes API Server using a CLI or UI.
• Kubernetes’ default command-line tool is called kubectl
• Kubernetes stores the file (an application’s desired state) in a database
called the Key-Value Store (etcd).
• Kubernetes then implements the desired state on all the relevant
applications within the cluster.
• Kubernetes continuously monitors the elements of the cluster to make sure
the current state of the application does not vary from the desired state.
Page 02-6
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
• Kubernetes master is also called as Control Plane.
• Kubernetes Maser is a collection of system services that makes up the
control plane of master.
• Kubernetes master control everything.
• Kubernetes cluster is made up of masters and nodes
• First create a kubernetes master which is first step to create the clusters.
• All container will be running in the node but not in the Kube masters.
• Get the node to join the clusters.
• Pods and container will be running on Nodes.
• Master will be only scheduling and replicating the containers across
nodes and make sure that configuration is satisfied which is made in the
beginning.
• There are 2 ways to access Kubernetes Master
• - Using CLI – Default Way where we can enable the dashboard.
• - Using GUI –
Page 02-7
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
• The Kubernetes Master (Master Node) receives input from a CLI
(Command-Line Interface) or UI (User Interface) via an API. These are the
commands you provide to Kubernetes.
• You define pods, replica sets, and services that you want Kubernetes to
maintain. For example, which container image to use, which ports to
expose, and how many pod replicas to run.
• You also provide the parameters of the desired state for the application(s)
running in that cluster.
• Following are key components of Kubernetes master
-API Server
The API Server is the front-end of the control plane and the
only component in the control plane that we interact
with directly. Internal system components, as well as external
user components, all communicate via the same API.
-Key-Value Store (etcd)
The Key-Value Store, also called etcd, is a database
Kubernetes uses to back-up all cluster data. It stores the entire configuration
and state of the cluster. The Master node queries etcd to retrieve
parameters for the state of the nodes, pods, and containers.
-Controller
The role of the Controller is to obtain the desired state from
the API Server. It checks the current state of the nodes it is tasked to control,
and determines if there are any differences, and resolves them, if
any.
-Scheduler
A Scheduler watches for new requests coming from the API
Server and assigns them to healthy nodes. It ranks the quality of the nodes
and deploys pods to the best-suited node. If there are no suitable
nodes, the pods are put in a pending state until such a node appears.
Page 02-8
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
• Node are workers/slave of kubernetes cluster.
• Worker nodes listen to the API Server for new work assignments; t
• They execute the work assignments and then report the results back to the
Kubernetes Master node.
• Following are the major components of Kubernetes.
-Kubelet
The kubelet runs on every node in the cluster. It is the
principal Kubernetes agent. By installing kubelet, the node’s CPU, RAM, and
storage become part of the broader cluster. It watches for tasks sent
from the API Server, executes the task, and reports back to the Master. It also
monitors pods and reports back to the control panel if a pod is
not fully functional. Based on that information, the Master can then decide how
to allocate tasks and resources to reach the desired state.
- Container Runtime
The container runtime pulls images from a container image
registry and starts and stops containers. A 3rd party software or plugin, such
as Docker, usually performs this function.
- Kube-proxy
The kube-proxy makes sure that each node gets its IP
address, implements local iptables and rules to handle routing and traffic load-
balancing.
- Pod
A pod is the smallest element of scheduling in Kubernetes.
Without it, a container cannot be part of a cluster. If you need to scale your
app, you can only do so by adding or removing pods.
The pod serves as a ‘wrapper’ for a single container with the
application code. Based on the availability of resources, the Master schedules
the pod on a specific node and coordinates with the container
runtime to launch the container
Page 02-9
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
1) kubelet
An agent that runs on each node in the cluster. It makes sure
that containers are running in a Pod.
The kubelet takes a set of PodSpecs that are provided
through various mechanisms and ensures that the containers described in
those PodSpecs are running and healthy. The kubelet doesn't
manage containers which were not created by Kubernetes.
2)kube-proxy
kube-proxy is a network proxy that runs on each node in your
cluster, implementing part of the Kubernetes Service concept.
kube-proxy maintains network rules on nodes. These network rules allow
network communication to your Pods from network sessions inside or outside
of your cluster.
kube-proxy uses the operating system packet filtering layer if
there is one and it's available. Otherwise, kube-proxy forwards the traffic itself.
3)Container runtime
The container runtime is the software that is responsible for
running containers.
Kubernetes supports several container
runtimes: Docker, containerd, CRI-O, and any implementation of
the Kubernetes CRI (Container Runtime Interface).
Page 02-10
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Page 02-11
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
• POD is a group of containers .
• A pod is the smallest element of scheduling in Kubernetes. Without it, a
container cannot be part of a cluster.
• If you need to scale your app, you can only do so by adding or removing
pods.
• The pod serves as a ‘wrapper’ for a single container with the application
code.
• Based on the availability of resources, the Master schedules the pod on a
specific node and coordinates with the container runtime to launch the
container.
• In instances where pods unexpectedly fail to perform their tasks,
Kubernetes does not attempt to fix them.
• Instead, it creates and starts a new pod in its place. This new pod is a
replica, except for the DNS and IP address.
• This feature has had a profound impact on how developers design
applications.
• Due to the flexible nature of Kubernetes architecture, applications no longer
need to be tied to a particular instance of a pod.
• Instead, applications need to be designed so that an entirely new pod,
created anywhere within the cluster, can seamlessly take its place.
• To assist with this process, Kubernetes uses services.
Page 02-12
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
How Do Kubernetes Services Work?
• Pods are associated with services through key-value pairs
called labels and selectors.
• A service automatically discovers a new pod with labels that match the
selector.
• This process seamlessly adds new pods to the service, and at the same
time, removes terminated pods from the cluster.
• For example, if the desired state includes three replicas of a pod and a
node running one replica fails, the current state is reduced to two pods.
Kubernetes observers that the desired state is three pods.
• It then schedules one new replica to take the place of the failed pod and
assigns it to another node in the cluster.
• The same would apply when updating or scaling the application by adding
or removing pods.
• Once we update the desired state, Kubernetes notices the discrepancy and
adds or removes pods to match the manifest file.
• The Kubernetes control panel records, implements, and runs background
reconciliation loops that continuously check to see if the environment
matches user-defined requirements.
Page 02-13
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Page 02-14
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
-The API Server is the front-end of the control plane and the only component
in the control plane that we interact with directly. Internal system components,
as well as external user components, all communicate via the same API.
-
Page 02-15
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Scheduler
Page 02-16
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
The Logic implemented by Controller is as follows
-Obtain Desire State
-Observe Current State
-Determine difference
-Reconcile Differences
Page 02-17
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Page 02-18
JPA with Hibernate 3.0 The Persistence Life Cycle
Instructor Notes:
Add instructor notes
here.
Page 02-19
