IT training kubernetes for java developers khotailieu

Co
m
pl
im
en
ts

Orchestrate Multi-Container
Applications with Ease

Arun Gupta

of

Kubernetes for
Java Developers



Kubernetes for Java
Developers

Orchestrate Multicontainer
Applications with Ease

Arun Gupta

Beijing

Boston Farnham Sebastopol

Tokyo


Kubernetes for Java Developers
by Arun Gupta
Copyright © 2017 O’Reilly Media Inc. All rights reserved.
Printed in the United States of America.
Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA
95472.
O’Reilly books may be purchased for educational, business, or sales promotional use.
Online editions are also available for most titles ( For more
information, contact our corporate/institutional sales department: 800-998-9938 or


Editors: Nan Barber and Brian Foster
Production Editor: Melanie Yarbrough
Copyeditor: Rachel Monaghan
Proofreader: Amanda Kersey

Interior Designer: David Futato
Cover Designer: Karen Montgomery
Illustrator: Rebecca Demarest

First Edition

June 2017:

Revision History for the First Edition
2017-06-08:

First Release

The O’Reilly logo is a registered trademark of O’Reilly Media, Inc. Kubernetes for
Java Developers, the cover image, and related trade dress are trademarks of O’Reilly
Media, Inc.
While the publisher and the author have used good faith efforts to ensure that the
information and instructions contained in this work are accurate, the publisher and
the author disclaim all responsibility for errors or omissions, including without limi‐
tation responsibility for damages resulting from the use of or reliance on this work.
Use of the information and instructions contained in this work is at your own risk. If
any code samples or other technology this work contains or describes is subject to
open source licenses or the intellectual property rights of others, it is your responsi‐
bility to ensure that your use thereof complies with such licenses and/or rights.

978-1-491-97326-4
[LSI]


Table of Contents

Foreword. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Preface. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
1. Kubernetes Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Pods
Replication Controllers
Replica Sets
Deployments
Services
Jobs
Volumes

Architecture

1
4
5
7
8
10
12
14

2. Deploying a Java Application to Kubernetes. . . . . . . . . . . . . . . . . . . . 17
Managing Kubernetes Cluster
Running Your First Java Application
Starting the WildFly Application Server
Managing Kubernetes Resources Using a Configuration File
Service Discovery for Java Application and a Database
Kubernetes Maven Plugin

17
25
27
31
33
39

3. Advanced Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Persistent Volume
Stateful Sets
Horizontal Pod Autoscaling

Daemon Sets

43
48
51
52
iii


Checking the Health of a Pod
Namespaces
Rolling Updates
Exposing a Service

53
54
56
58

4. Administration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Cluster Details
Application Logs
Debugging Applications
Application Performance Monitoring

59
62
63
66

5. Conclusion. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

iv

|

Table of Contents


Foreword

I had the pleasure of meeting Arun at a meetup last year. He is a
truly unique individual with a talent for explaining complex techni‐
cal concepts so a wide range of people can understand them. The
topic he was discussing that evening was Docker Swarm, and I left
feeling like I could create my own Swarm app.
Arun was an early member of the Java software development team
at Sun Microsystems and is now a prolific speaker and writer on
Java-related topics. You can download his previous ebook, Docker
for Java Developers, and the accompanying webinar, “Run Java in
Docker Containers with NGINX”, from the NGINX website.
Now, in this ebook, Arun introduces key Kubernetes concepts such
as pods—collections of containers—and shows you how these enti‐
ties interact with your Java application. The eruption of containers
into the development landscape, led by Docker, highlights the need
for ways to manage and orchestrate them. Kubernetes is the leading
container orchestration tool.
NGINX is widely used with both technologies. NGINX works well
with containers; it is one of the most frequently downloaded appli‐
cations on Docker Hub, with over 10 million pulls to date. And

NGINX is seeing increasing use with Kubernetes, including as an
ingress controller. Arun’s goal is to get you, as a Java developer, up to
speed with Kubernetes in record time. This book in an important
tool to help you carry out this mission. We hope you enjoy it.
— Faisal Memon, Product
Marketer, NGINX, Inc.

v



Preface

A Java application typically consists of multiple components, such as
an application server, a database, and a web server. Multiple instan‐
ces of each component are started to ensure high availability. The
components usually dynamically scale up and down to meet the
always-changing demands of the application. These multiple com‐
ponents are run on a cluster of hosts or virtual machines to avoid a
single point of failure.
In a containerized solution, each replica of each component is a
container. So a typical application is a multicontainer, multihost
application. A container orchestration system is required that can
manage the cluster; schedule containers efficiently on different
hosts; provide primitives, such as service discovery, that allow differ‐
ent containers to talk to each other; and supply network storage that
can store database-persistent data. This system allows developers to
focus on their core competency of writing the business logic as
opposed to building the plumbing around it.
Kubernetes is an open source container orchestration framework

that allows simplified deployment, scaling, and management of con‐
tainerized applications. Originally created by Google, it was built
upon the company’s years of experience running production work‐
loads in containers. It was donated to Cloud Native Computing
Foundation (CNCF) in March 2016 to let it grow as a truly vendorindependent project. Different Kubernetes projects can be found on
GitHub.
This book is targeted toward Java developers who are interested in
learning the basic concepts of Kubernetes. The technology and the
terminology are rapidly evolving, but the basics still remain relevant.
vii


Chapter 1 explains them from the developer and operations per‐
spective. Chapter 2 explains how to create a single-node local devel‐
opment cluster and how to get started with a multinode cluster. It
also covers a simple Java application communicating with a database
running on Kubernetes. Chapter 3 gets into more advanced con‐
cepts like stateful containers, scaling, performing health checks and
rolling updates of an application, and sharing resources across the
cluster. Chapter 4 details administrative aspects of Kubernetes. The
examples in this book use the Java programming language, but the
concepts are applicable for anybody interested in getting started
with Kubernetes.

Acknowledgments
I would like to express gratitude to the people who made writing
this book a fun experience. First and foremost, many thanks to
O’Reilly for providing an opportunity to write it. The team provided
excellent support throughout the editing, reviewing, proofreading,
and publishing processes. At O’Reilly, Brian Foster believed in the

idea and helped launch the project. Nan Barber was thorough and
timely with her editing, which made the book fluent and consistent.
Thanks also to the rest of the O’Reilly team, some of whom we may
not have interacted with directly, but who helped in many other
ways. Paul Bakker (@pbakker) and Roland Huss (@ro14nd) did an
excellent technical review of the book, which ensured that the book
stayed true to its purpose and explained the concepts in the simplest
possible ways. A vast amount of information in this book is the
result of delivering the “Kubernetes for Java Developers” presenta‐
tion all around the world. A huge thanks goes to all the workshop
attendees whose questions helped clarify my thoughts. Last but not
least, I seek forgiveness from all those who have helped us over the
past few months and whose names I have failed to mention.

viii

|

Preface


CHAPTER 1

Kubernetes Concepts

Kubernetes is an open source orchestration system for managing
containerized applications across multiple hosts, providing basic
mechanisms for the deployment, maintenance, and scaling of appli‐
cations.
Kubernetes, or “k8s” or “kube” for short, allows the user to declara‐

tively specify the desired state of a cluster using high-level primi‐
tives. For example, the user may specify that she wants three
instances of the WildFly server container running. Kubernetes’ selfhealing mechanisms, such as autorestarting, rescheduling, and repli‐
cating containers, then converge the actual state toward the desired
state.
Kubernetes supports Docker and Rocket containers. An abstraction
around the containerization layer allows for other container image
formats and runtimes to be supported in the future. But while multi‐
ple container formats are supported, Docker is by far the most prev‐
alent format used with Kubernetes.
All resource files in this chapter are available on GitHub.

Pods
A pod is the smallest deployable unit that can be created, scheduled,
and managed. It’s a logical collection of containers that belong to an
application. Pods are created in a namespace. All containers in a pod
share the namespace, volumes, and networking stack. This allows

1


containers in the pod to “find” each other and communicate using
localhost.
Each resource in Kubernetes can be defined using a configuration
file. For example, a WildFly pod can be defined with the configura‐
tion file shown in Example 1-1.
Example 1-1. Pod configuration
apiVersion: v1
kind: Pod
metadata:

name: wildfly-pod
labels:
name: wildfly-pod
spec:
containers:
- name: wildfly
image: jboss/wildfly:10.1.0.Final
ports:
- containerPort: 8080

This configuration file uses the following properties:
apiVersion defines the version of the Kubernetes API. This is
now fixed at v1 and allows for the API to evolve in the future.
kind defines the type of this resource—in this example, that
value is Pod.
metadata allows you to attach information about the resource.

Each resource must have a name attribute. If this attribute is not
set, then you must specify the generateName attribute, which is
then used as a prefix to generate a unique name. Optionally, you
can use a namespace property to specify a namespace for the
pod. Namespaces provide a scope for names and are explained
further in “Namespaces” on page 54.
In addition to these properties, there are two types of metadata:

metadata.labels and metadata.annotations. They both are

defined as key/value pairs.

Labels are designed to specify identifying attributes of the object

that are meaningful and relevant to the users, but which do not
2

| Chapter 1: Kubernetes Concepts


directly imply semantics to the core system. Multiple labels can
be attached to a resource. For example, name: wildfly-pod is a
label assigned to this pod. Labels can be used to organize and to
select subsets of objects.
Annotations are defined using metadata.annotations[]. They
are designed to be nonidentifying arbitrary information
attached to the object. Some information that can be recorded
here is build/release information, such as release IDs, Git
branch, and PR numbers.
spec defines the specification of the resource, pod in our case.
containers defines all the containers within the pod.

Each container must have a uniquely identified name and image
property. name defines the name of the container, and image
defines the Docker image used for that container. Some other
commonly used properties in this section are:
args
A command array containing arguments to the entry point
env
A list of environment variables in key:value format to set
in the container
ports define the list of ports to expose from the container.

WildFly runs on port 8080, and thus that port is listed here.

This allows other resources in Kubernetes to access this con‐
tainer on this port.

In addition, restartPolicy can be used to define the restart policy
of all containers within the pod. volumes[] can be used to list vol‐
umes that can be mounted by containers belonging to the pod.
Pods are generally not created directly, as they do not survive node
or scheduling failures. They are mostly created using a replication
controller or deployment.
More details about the pod configuration file are available at the
Kubernetes website.

Pods

|

3


Replication Controllers
A replication controller (RC) ensures that a specified number of pod
“replicas” are running at any one time. Unlike manually created
pods, the pods maintained by a replication controller are automati‐
cally replaced if they fail, get deleted, or are terminated. A replica‐
tion controller ensures the recreation of a pod when the worker
node fails or reboots. It also allows for both upscaling and downscal‐
ing the number of replicas.
A replication controller creating two instances of a WildFly pod can
be defined as shown in Example 1-2.
Example 1-2. Replication controller configuration

apiVersion: v1
kind: ReplicationController
metadata:
name: wildfly-rc
spec:
replicas: 2
selector:
app: wildfly-rc-pod
template:
metadata:
labels:
app: wildfly-rc-pod
spec:
containers:
- name: wildfly
image: jboss/wildfly:10.1.0.Final
ports:
- containerPort: 8080

The apiVersion, kind, metadata, and spec properties serve the
same purpose in all configuration files.
This configuration file has the following additional properties:
The value of kind is ReplicationController, which indicates
that this resource is a replication controller.
replicas defines the number of replicas of the pod that should
concurrently run. By default, only one replica is created.

4

| Chapter 1: Kubernetes Concepts

selector is an optional property. The replication controller
manages the pods that contain the labels defined by the
spec.selector property. If specified, this value must match
spec.template.metadata.labels.

All labels specified in the selector must match the labels on the
selected pod.
template is the only required field of spec in this case. The

value of this field is exactly the same as a pod, except it is nested
and does not have an apiVersion or kind. Note that spec.tem
plate.metadata.labels matches the value specified in
spec.selector. This ensures that all pods started by this repli‐
cation controller have the required metadata in order to be
selected.
Each pod started by this replication controller has a name in the for‐
mat <name-of-the-RC>-<hash-value-of-pod-template>. In our
case, all names will be wildfly-rc-xxxxx, where xxxxx is the hash
value of the pod template.
More details about replication controllers are available at the Kuber‐
netes website.

Replica Sets
Replica sets are the next-generation replication controllers. Just like a
replication controller, a replica set ensures that a specified number
of pod replicas are running at any one time. The only difference
between a replication controller and a replica set is the selector sup‐
port.

For replication controllers, matching pods must satisfy all of the
specified label constraints. The supported operators are =, ==, and !
=. The first two operators are synonyms and represent equality. The
last operator represents inequality.
For replica sets, filtering is done according to a set of values. The
supported operators are in, notin, and exists (only for the key).
For example, a replication controller can select pods such as envi
ronment = dev. A replica set can select pods such as environment
in ["dev", "test"].

Replica Sets

|

5


A replica set creating two instances of a WildFly pod can be defined
as shown in Example 1-3.
Example 1-3. Replica set configuration
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: wildfly-rs
spec:
replicas: 2
selector:
matchLabels:
app: wildfly-rs-pod
matchExpressions:

- {key: tier, operator: In, values: ["backend"]}
- {key: environment, operator: NotIn, values: ["prod"]}
template:
metadata:
labels:
app: wildfly-rs-pod
tier: backend
environment: dev
spec:
containers:
- name: wildfly
image: jboss/wildfly:10.1.0.Final
ports:
- containerPort: 8080

The key differences between Examples 1-2 and 1-3 are as follows:
The apiVersion property value is extensions/v1beta1. This
means that this object is not part of the “core” API at this time,
but is only a part of the extensions group. Read more about
API versioning at the Kubernetes GitHub page.
The value of kind is Replicaset and indicates the type of this
resource.
matchLabels defines the list of labels that must be on the

selected pod. Each label is a key/value pair.

wildfly-rs-pod is the exact label that must be on the selected

pod.

6

| Chapter 1: Kubernetes Concepts


matchExpressions defines the list of pod selector requirements.

Each expression can be defined as a combination of three key/
value pairs. The keys are key, operator, and values. The values
are one of the keys from the labels; one of the operators In,
NotIn, Exist, or DoesNotExist; and a nonempty set of values,
respectively.
All the requirements, from both matchLabels and matchExpres
sions, must match for the pod to be selected.
Replica sets are generally never created on their own. Deployments
own and manage replica sets to orchestrate pod creation, deletion,
and updates. See the following section for more details about
deployments.
More details about replica sets are available at the Kubernetes web‐
site.

Deployments
Deployments provide declarative updates for pods and replica sets.
You can easily achieve the following functionality using deployment:
• Start a replication controller or replica set.
• Check the status of deployment.
• Update deployment to use a new image, without any outages.
• Roll back deployment to an earlier revision.
A WildFly replica set with three replicas can be defined using the
configuration file shown in Example 1-4.

Example 1-4. Deployment configuration
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: wildfly-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: wildfly

Deployments

|

7


spec:
containers:
- name: wildfly
image: jboss/wildfly:10.1.0.Final
ports:
- containerPort: 8080

Two main differences from Example 1-2 are:
• The apiVersion property value is extensions/v1beta1. This
means that this object is not part of the “core” API at this time
and is only a part of the extensions group. Read more about

API versioning at the Kubernetes GitHub page.
• The value of the kind property is Deployment, which indicates
the type of resource.
More details about deployment are available in the Kubernetes user
guide.

Services
A pod is ephemeral. Each pod is assigned a unique IP address. If a
pod that belongs to a replication controller dies, then it is recreated
and may be given a different IP address. Further, additional pods
may be created using replication controllers. This makes it difficult
for an application server such as WildFly to access a database such
as Couchbase using its IP address.
A service is an abstraction that defines a logical set of pods and a
policy by which to access them. The IP address assigned to a service
does not change over time, and thus can be relied upon by other
pods. Typically, the pods belonging to a service are defined by a label
selector. This is similar to how pods belong to a replication control‐
ler.
This abstraction of selecting pods using labels enables a loose cou‐
pling. The number of pods in the replication controller may scale up
or down, but the application server can continue to access the data‐
base using the service.
Multiple resources, such as a service and a replication controller,
may be defined in the same configuration file. In this case, each
resource definition in the configuration file needs to be separated by
---.
8

|

Chapter 1: Kubernetes Concepts


For example, a WildFly service and a replication controller that cre‐
ates matching pods can be defined as shown in Example 1-5.
Example 1-5. Service configuration
apiVersion: v1
kind: Service
metadata:
name: wildfly-service
spec:
selector:
app: wildfly-rc-pod
ports:
- name: web
port: 8080
--apiVersion: v1
kind: ReplicationController
metadata:
name: wildfly-rc
spec:
replicas: 2
template:
metadata:
labels:
app: wildfly-rc-pod
spec:
containers:
- name: wildfly

image: jboss/wildfly:10.1.0.Final
ports:
- containerPort: 8080

Multiple resources are created in the order they are specified in the
file.
In this configuration file:
There are two resources: a service and a replication controller.
The service selects any pods that contain the label app:
wildfly-rc-pod. The replication controller attaches those labels
to the pod.

port defines the port on which the service is accessible. A ser‐
vice can map an incoming port to any target port in the con‐

Services

|

9


tainer using targetPort. By default, targetPort is the same as
port.
A service may expose multiple ports. In this case, each port
must be given a unique name:
ports:
- name: web
port: 8080

--- is the separator between multiple resources.

By default, a service is available only inside the cluster. It can be
exposed outside the cluster, as covered in “Exposing a Service” on
page 58.
More details about services are available at the Kubernetes website.

Jobs
A job creates one or more pods and ensures that a specified number
of them successfully complete. When the specified number of pods
has successfully completed, the job itself is complete. The job will
start a new pod if the pod fails or is deleted due to hardware failure.
This is different from a replication controller or a deployment,
which ensure that a certain number of pods are always running. If a
pod in a replication controller or deployment terminates, it is restar‐
ted. This makes replication controllers and deployments both longrunning processes, which is well suited for an application server
such as WildFly. But a job is completed only when the specified
number of pods successfully completes, which is well suited for tasks
that need to run only once. For example, a job may convert one
image format to another. Restarting this pod in a replication con‐
troller would not only cause redundant work but may even be harm‐
ful in certain cases.
There are two main types of jobs:
Nonparallel jobs
Job specification consists of a single pod. The job completes
when the pod successfully terminates.
Parallel jobs
A predefined number of pods successfully completes. Alterna‐
tively, a work queue pattern can be implemented where pods can
10

|

Chapter 1: Kubernetes Concepts


coordinate among themselves or with an external service to
determine what each should work on.
A nonparallel job can be defined using the configuration file shown
in Example 1-6.
Example 1-6. Job configuration
apiVersion: batch/v1
kind: Job
metadata:
name: wait
spec:
template:
metadata:
name: wait
spec:
containers:
- name: wait
image: ubuntu
command: ["sleep", "20"]
restartPolicy: Never

In this configuration file:
Jobs are defined in their own API group using the path
batch/v1.
The Job value defines this resource to be of the type job.

spec specifies the job resource as a pod template. This is similar

to a replication controller.

This job uses the base image of ubuntu. Usually, this will be a
custom image that will perform the run-once task.
By default, running the ubuntu image starts the shell. In this
case, command overrides the default command and waits for 20
seconds. Note, this is only an example usage. The actual task
would typically be done in the image itself.
Each pod template must explicitly specify the restartPolicy
equal to Never or OnFailure. A value of Never means that the
pod is marked Succeeded or Failed depending upon the num‐
ber of containers running and how they exited. A value of
Jobs

|

11


OnFailure means the pod is restarted if the container in the pod
exits with a failure. More details about these policies are avail‐
able at the Kubernetes website.

Kubernetes 1.4 introduced a new alpha resource called Scheduled
Job. This resource was renamed to CronJob starting in version 1.5.
CronJob allows you to manage time-based jobs. There are two pri‐
mary use cases:

• Run jobs once at a specified point in time.
• Run jobs repeatedly at a specified point in time.
Note, this is an alpha resource, so it needs to be explicitly enabled.

Volumes
Pods are ephemeral and work well for a stateless container. They are
restarted automatically when they die, but any data stored in their
filesystem is lost with them. Stateful containers, such as Couchbase,
require data to be persisted outside the lifetime of a container run‐
ning inside a pod. This is where volumes help.
A volume is a directory that is accessible to the containers in a pod.
The directory, the medium that backs it, and the contents within it
are determined by the particular volume type used. A volume out‐
lives any containers that run within the pod, and the data is pre‐
served across container restarts.
Multiple types of volumes are supported. Some of the commonly
used volume types are shown in Table 1-1.
Table 1-1. Common volume types in Kubernetes
Volume type
hostPath

Mounts into your pod
A file or directory from the host node’s filesystem

nfs

Existing Network File System share

awsElasticBlockStore An Amazon Web Service EBS volume
gcePersistentDisk

A Google Compute Engine persistent disk

Two properties need to be defined for a volume to be used inside a
pod: spec.volumes to define the volume type, and spec.contain
ers.volumeMounts to specify where to mount the volume. Multiple
12

|

Chapter 1: Kubernetes Concepts


volumes in a pod and multiple mount points in a container can be
easily defined. A process in a container sees a filesystem view com‐
posed of the Docker image and volumes in the pod.
A volume defined in the pod configuration file is shown in
Example 1-7.
Example 1-7. Volume configuration
apiVersion: v1
kind: Pod
metadata:
name: couchbase-pod
labels:
name: couchbase-pod
spec:
containers:
- name: couchbase
image: arungupta/couchbase-oreilly:k8s
ports:

- containerPort: 8091
volumeMounts:
- mountPath: /var/couchbase/lib
name: couchbase-data
volumes:
- name: couchbase-data
hostPath:
path: /opt/data

In this configuration file:
The pod in the replication controller uses the image at arun‐
gupta/oreilly-couchbase:k8s. This image is created using Couch‐
base. It uses the Couchbase REST API to configure the
Couchbase server and create a sample bucket in it.
The volumeMounts property defines where the volume is moun‐
ted in the container.
mountPath defines the path where the volume is mounted in the

container.

name refers to a named volume defined using volumes. This
value must match the value of the name property of one of the
volumes defined in volumes.

Volumes

|

13

volumes defines the volumes accessible to the pod.
hostPath defines the type of volume mounted. This volume

type is mounting a directory from host node’s filesystem. A dif‐
fere volume type may be specified here.
/opt/data is the path in the host node filesystem.
You can create an Amazon Elastic Block Storage (EBS) volume using
the aws ec2 create-volume command. Alternatively, you can cre‐
ate a Google Cloud persistent disk using the gcloud compute disks
create command. You can mount these volumes in the container
using the awsElasticBlockStore and gcePersistentDisk volume
types, respectively.
More details about volumes, including different types of volumes
and how to configure them, are available at the Kubernetes website.

Architecture
The key components of the Kubernetes architecture are shown in
Figure 1-1.

Figure 1-1. Kubernetes architecture
A Kubernetes cluster is a set of physical or virtual machines and
other infrastructure resources that are used to run your applications.

14

|

Chapter 1: Kubernetes Concepts

Each machine is called a node. The machines that manage the clus‐
ter are called master nodes, and the machines that run the contain‐
ers are called worker nodes. Each node handles the necessary
services to run application containers.
The two typical interaction points with Kubernetes are kubectl and
the client application running in the internet.

Master nodes
A master node is a central control plane that provides a unified view
of the cluster. You can easily create a Kubernetes cluster with a single
master node for development. Alternatively, you could create a
Kubernetes cluster with high availability with multiple master
nodes. Let’s look at the key components in the master node:
kubectl

This is a command-line tool that send commands to the master
node to create, read, update, and delete resources. For example,
it can request to create a pod by passing the pod configuration
file, or it can query more details about the replicas running for a
replica set. It reads container manifests as YAML or JSON files
that describe each resource. A typical way to provide this mani‐
fest is using the configuration file as shown in the previous sec‐
tions. This process is explained more in “Running Your First
Java Application” on page 25.
API server
Each command from kubectl is translated into a REST API and
issued to the API server running inside the master node. The
API server processes REST operations, validates them, and per‐
sists the state in a distributed watchable storage. This is imple‐

mented using etcd for Kubernetes.
Scheduler
The scheduler works with the API server to schedule pods to
the nodes. The scheduler has information about resources avail‐
able on the worker nodes, as well as the ones requested by the
pods. It uses this information to decide which node will be
selected to deploy a specific pod.
Controller manager
The controller manager is a daemon that watches the state of
the cluster using the API server for different controllers and
Architecture

|

15