 On August 9, 2006, Eric Schmidt, formal CEO of Google, first proposed the concept

of cloud computing at the search engine conference.

 Pain points of application deployment on the cloud:

 Redeployment：

 The local environment is inconsistent with the cloud environment.

 Historical data

 Images: To run an application, you need to drag a large-size image (in GB),
which occupies a lot of system resources for storage. In addition, the
virtualization technology inevitably causes extra resource consumption and
occupation.

 Note: This course focuses on Linux containers.

 Cloud Foundry is the first open source PaaS platform in the industry. It was initially
developed by VMware and then became an open source platform. In 2015, the
Cloud Foundry Foundation was established.
 The packaging system in the PaaS project is actually used for packaging
applications. However, due to the inconsistency between the local environment
and cloud environment, the adaptation workload is heavy during packaging.
 An application may consist of multiple services, and each service has its unique
dependency. In addition, applications may need to be deployed in different
environments. Therefore, a large amount of workload is required for running
environment adaption during the development, testing, deployment, and O&M of
an application.
 Docker images are used to package the OS that an application runs, ensuring that
the local environment is consistent with the cloud environment. This frees O&M
personnel from repeated work.
 Docker was originally dotCloud. In 2013, dotCloud determined to open its
container project Docker. In 2017, the Docker project was renamed the Moby
project.

 Docker is a term derived from dock worker, which means dockers, that is, the
persons who load and unload goods from ships.

 Docker has joined the Linux Foundation and complies with the Apache 2.0
protocol.

 Docker is a container solution that implements packaging, transportation, and

running of any application. Docker facilitates building, shipping, and running of
containers, which can unify the entire development, testing, and deployment
environment and process, thereby greatly reducing the O&M cost.

 Note: The pictures are from the GitHub and Docker official websites.
 Container is not a new concept. However, after Docker encapsulates a container,
the concept of the encapsulated container is similar to that of a (cargo) container.
The Docker container technology is regarded as the innovation and revolution in
the software industry because it changes the development and deployment modes
of software, reduces costs, and improves efficiency. Docker introduces the
container technology to the world.

 Another major reason for the emerging of the container technology is the good
ecosystem of Linux.

 In addition to the Docker project, there are other containers. For example, rkt from
CoreOS and Imctfy (stopped) from Google.

 CoreOS was acquired by Red Hat in January 2018.

 Note: The picture is from the Docker official website.
 Containers are more agile and provide higher performance than VMs.
 Container orchestration is used to manage a series of operations for defining, creating,
and configuring a container. Technically, large-scale applications of containers need to
be managed and scheduled by the container orchestration engine in a unified manner.
Commercially, users' services or applications need to be deployed on the platform,
because users are willing to pay for the tools with platform capabilities.
 Typically, container-based applications use the microservice architecture. In this
architecture, applications are divided into different components and run in their own
containers as services. These services are provided externally through APIs. To ensure
high availability of applications, each component may run in multiple same containers.
These containers form a cluster. Containers in the cluster are dynamically created,
migrated, and destroyed based on service requirements. Such a microservice
architecture-based application system is actually a dynamic and scalable system. This
poses a new requirement for the deployment environment, and an efficient way is
required to manage container clusters. In this case, the container orchestration engine
emerges and meets such a requirement
 In December 2014, Docker released the container cluster company project Swarm.
Swarm uses the native container management API of Docker to manage clusters and
can be seamlessly integrated with the Docker project.
 The cluster management project Mesos of Mesosphere has a two-layer scheduling
mechanism (framework+scheduler) and can manage tens of thousands of nodes. It has
experience in managing ultra-large-scale clusters. Mesos was originally a big data
resource management project and can also support PaaS services.
 In June 2014, Google released the Kubernetes project. (CNCF community)
 In October 2017, Docker announced that the Kubernetes project would be embedded
in the main product Docker enterprise edition.
 In July 2015, Google and Red Hat initiated the establishment of the CNCF
foundation, which belongs to the Linux foundation.

 Note: The picture is from the CNCF official website.

 This is the OCI specifications.

 On June 22, 2015, Docker, CoreOS, Google, and Red Hat announced that
Docker donated Libcontainer to a neutral foundation for management and
renamed it the RunC project. Based on the RunC project, these companies
formulate a set of container and image standards and specifications.

 Libcontainer: library required for container running released by Docker. It is the

predecessor of RunC.

 The OCI specifications actually separate the runtime and container images from
the Docker project.

 Note: The picture is from the Docker official website.

 Docker does not interact with the kernel directly. It interacts with the kernel using
a lower-layer tool.

 Libcontainer: library required for container running released by Docker. RunC is

evolved from Libcontainer.

 Libcontainer provides the following functions: Creates and initializes

containers and manages container lifecycles.

 The working process of Libcontainer is as follows: Docker collects and sorts

the information required for running a container. The information will be
summarized in a Config structure. Libcontainer creates a container based on
the information in the Config structure and manages the container lifecycles.

 LXC: Linux Container

 Note: The preceding table lists only the runtime specifications related to Linux
containers.

 Reference: https://github.com/opencontainers/runtime-spec/blob/master/spec.md
 Docker indicates the container engine, that is, Docker engine.

 Docker engine is a client/server application. Docker engine consists of the

following components:

 Server: A program that runs for a long time and is called a daemon process

 Docker daemon is used to create and manage a Docker object, such as

a container image, container, network, and volume.

 Command line interface client (Docker CLI):

 The CLI uses the Docker RESTful API to interact with the Docker daemon
using scripts or CLI commands.

 A RESTful API: The client can use the API to communicate with the daemon
process.

 Note: The picture is from the Docker official website.

 This slide describes how components work together in the Docker architecture.
 Docker client: Docker is an application that uses the C/S architecture. The Docker
client initiates a request using the Docker commands. On the user interface, users
can communicate with the Docker daemon.
 Docker daemon: To be simple, the Docker daemon receives requests from clients,
implements the functions required by the requests, and returns the corresponding
results for the requests. Docker daemon is the core engine that drives the whole
Docker function. Docker daemon implements its functions on containers, images,
and storage and involves implementation and interaction of multiple modules.
 Containers:
 Containers are based on images and provide a standard and isolated running
environment for images.
 Docker containers are software containers. You can install any software
application and library file and configure any running environment. When
transferring and deploying applications, development and O&M personnel
do not need to know what software installed in the container or how to
configure the software.
 Docker image: A container provides a complete and isolated running environment,
and the image is a static display of the running environment.
 Registry: Registry is a repository for storing images. Registry is an independent
open source project. Enterprises can use Registry images to create private
repositories.

 Note: The picture is from the Docker official website.

 The container ID on this slide is also called full-id.

 Common options after docker run:

 -d: Starting a container on the background

 -p: Mapping the container port to the host port

 -it: Interacting with a container using a command line terminal after the
container is started

 -h: Specifying the host name of a container

 Identifiers of a container on a host:

 CONTAINER ID: Container ID, which contains the first 12 characters of the
container full-id and is also called short-id

 NAMES: Container name, which is automatically allocated by Docker or

specified by a parameter
 Commands for containerized application lifecycle management:

 docker create: Creating a container

 docker start: Starting a container

 docker run: Creating and running a container

 docker pause: Pausing a container

 docker unpause: Restoring a container

 docker restart: Restarting a container

 docker stop: Stopping a running container

 docker rm: Deleting a container in the terminated state

 docker kill: Killing the container process

 The docker stop command is used to send a SIGTERM signal to the container
process. The docker kill command is used to send a SIGKILL signal to the container
process.
 Answers:

 ABCD

 Host file system resources

 docker container prune

 The major difference between Linux versions lies on the rootfs, and the difference
between Linux kernel is small.

 A typical Linux OS requires at least the following two file systems to run properly:

 boot file system (bootfs): contains Boot Loader and kernel. The user cannot
modify this file system. The bootfs file system is loaded when the Linux OS is
started. After the system is started, the entire kernel is loaded to the memory.
In this case, the bootfs is uninstalled to release the occupied memory. bootfs
is the same for different Linux versions with the same kernel version.

 root file system (rootfs): contains the typical directory structure, such as /dev,
/proc, /bin, /etc, /lib, /usr, and /tmp, and all configuration files, binary files,
and library files required for running user applications. This file system varies
by Linux version and can be modifies by users.
 For an application, the OS is the most complete dependency required for its
running.

 The container image packs the entire OS required for running the application,
thereby ensuring the high consistency between the local and cloud environments.
For software development, container images streamline the "development-test-
deployment" process.

 Container images provide various files in a set of image file systems. Kernel-related
modules or features depend on the host where the containers reside.
 scratch is an empty image provided by Docker.

 The preceding figure shows the top 5 base images on Docker Hub.
 The container image adopts a layer model and has the image and container layers.

 Image layer: Read-only. Each image layer can be shared.

 Container layer: Read/write and loaded to the image layer when the
container is started.

 Container images

 All image layers in a complete image are combined to form a unified file
system. Users can view only the files at the top layer in the container layer.

 The image layers enable images to be created incrementally. In this way, the
amount of data obtained and pushed each time is much smaller than that of
the entire image. In addition, the actual storage space occupied by container
images on the host or Registry is much smaller than the total space occupied
by all container images, reducing space occupation.

 Note: The picture is from the Docker official website.

 Multiple containers can share one container image, and an independent writable
container layer of each container enables each container have independent data.

 Note: The picture is from the Docker official website.

 The directories in the overlay2 file system are described as follows:

 LowerDir: points to the image layer and stores the image layer.

 UpperDir: points to the container layer. After a file is created in the container,
the file is stored in this directory.

 MergedDir: refers to the container mount point. LowerDir and UpperDir are
integrated to provide a unified view for the container as the root file system.

 WorkDir: used to implement the copy_up operation.

 Docker image layers are implemented based on the capabilities of Union FS.

 Union FS is the technical basis for the implementation of Docker images. It is a

lightweight high-performance hierarchical file system that allows modifications in
the file system to be submitted and superimposed layer by layer. This feature
enables images to be implemented and inherited using layers. Different directories
can be mounted to the same virtual file system.

 The following uses Overlay2 as an example. Overlay2 is a stack file system. It

depends on and is built on other file systems (such as Fourth Extended File
System (ext4fs) and XFS). It is not directly used for the disk space structure
division, but is used to only combine different directories in the original
underlying file system and presents the combined directories to users, which
is the union mount technology.

 Note: In this course, Union FS supported by Docker is described in the chapter

about container storage.
 All storage drivers support the image layers and the Copy-on-Write (CoW) policy.
 "docker commit" indicates a process of packaging the top layer (readable and
writable) and the read-only layers of the original container image into a new image
after the container is started.
 The "docker history" command output displays the image building process and
shows the image layers from top to bottom.
 If the Dockerfile is used to build images, the first valid information (except
annotations) of the Dockerfile must be the basic image information with the
maintenance engineer information following. After the maintenance engineer
information is the image operation commands. Various images are constructed
because of different operation commands. The last are the container startup
commands, which are used as the default startup commands for setting the image.
 The Dockerfile commands are classified into the following two types based on
their functions:
 Building commands: used to build an image. A specified operation is not
performed on a container running the image.
 Setting commands: used to set the attributes of an image. A specified
operation is performed on a container running the image.
 Note the following when using the Dockerfile command set:
 The commands that are run after the "RUN" command must be supported by
the basic image. For example, if the basic image uses CentOS, only the
CentOS commands can be used for software management.
 The difference between the "ADD" and "COPY" commands: In the "ADD"
command, if "src" is a compressed file, the file is automatically decompressed
to "dest".
 If there are multiple "CMD" commands in the Dockerfile, only the last
command is executed.
 If there are multiple "ENTRYPOINT" commands in the Dockerfile, only the last
command is executed.
 The difference between the "CMD" and "ENTRYPOINT" commands: When the
"Docker run" command matches the "CMD" command, the "CMD" command
will be replaced.
 For details, visit https://docs.docker.com/engine/reference/builder/.
 After the "docker build" command is executed, all files and subdirectories in the
build context are sent to the Docker daemon, as "Sending build context to Docker
daemon" is displayed in the preceding command output.

 During the execution, the Dockerfile starts the temporary container, executes a
command in the temporary container to modify the container content, saves the
container as an image to generate a new image layer, and deletes the temporary
container. If there are multiple commands in the Dockerfile, the process is
repeated until the execution is complete.
 This slide explains the image building process on the previous slide.
 "Using cache" indicates that the container image cache is used.

 When you run the "docker build" command to create an image, the "--no-cache"
parameter indicates that the image cache is not used.
 You need to name the image to implement large-scale management.
 The Dockerfile of an image can be queried from Docker Hub.
 Advantages of Docker Hub:

 Provides a large number of Docker images for developers to download and

use for free.

 Provides a complete account management system to provide paid capacity

expansion for users.

 Supports deploying servers in distributed mode and supports load balancing.

 Allows users to upload, download, query, and delete images, and set image
attributes.

 Supports online image compilation.

 Uses distributed storage at the back end for disaster recovery (DR) and
backup.

 Its core is Docker distribution, which is designed and maintained in the open
source community and will be continuously updated and improved.

 The Docker Hub enterprise edition provides one-stop solutions for enterprise
users.

 The Dockerfile of each image can be queried from Docker Hub.

 In addition to using the public registry, enterprises can set up private registries
based on their own requirements.

 Common commands for container image operations:

 docker push: used to upload the image to the registry.

 docker pull: used to download the image from registry.

 docker rmi: used to delete the local image.

 docker images: used to displays local image.

 docker seasch: used to search for images on Docker Hub.

 docker tag: used to tag the image.

 docker history: used to show the image building process.

 docker commit: used to save the container as an image.

 docker build: used to create an image using the Dockerfile.

 Before pushing images to the registry, add {"insecure-registries":
["192.168.137.99:1000"]} to the "/etc/docker/daemon.json" file.
 Answers:

 T

 T

 F
 This chapter describes Docker networks in the single-host scenario.
 When the none network is used, the container does not have a network interface
for external communication. Therefore, the none network is used only for back-
end job processing scenarios that do not require a network.
 When the host network is used, containers share the network and interfaces of the
Docker host.
 When the Docker DaemonSet process is started for the first time, a bridge named
docker0 is created on the current node, and it is configured to use the
172.17.0.0/16 network by default. This network is an implementation of the bridge
model and is used by default when Docker containers are created.
 When the Docker DaemonSet process is started for the first time, a bridge named
docker0 is created on the current node, and it is configured to use the
172.17.0.0/16 network by default. This network is an implementation of the bridge
model and is used by default when Docker containers are created.
 For a network that uses the bridge driver, the container engine creates two virtual
Ethernet devices for each network interface. One is configured as the interface
device of the container, and the other is connected to the specified virtual bridge
device (docker0 by default) on the host.
 Answers

 F

 D
 The container layer managed by a storage driver usually stores the data of
stateless applications, that is, data that does not need to be stored persistently.

 You are advised to select the default storage driver of the Linux distribution
version.

 For details, see https://docs.docker.com/storage/storagedriver/select-storage-

driver/.
 The container layer managed by a storage driver usually stores the data of
stateless applications, that is, data that does not need to be stored persistently.
For data that needs to be stored persistently, volume or bind mount is required.

 A volume or bind mount is a directory or file in the file system of a host

machine.

 The lifecycle of data stored on a volume or bind mount is independent of the

container. That is, after the container is deleted, the data on the volume or
bind mount still exists.

 The figure is from the Docker official website. This chapter focuses on volume and
bind mount, not tmpfs mount.
 Volumes are managed by Docker. When a volume is used, a new directory is
created in the Docker storage directory on the host. Docker manages the contents
in the directory.

 Precautions：

 The content of a volume is beyond the lifecycle of the container. After the
container is deleted, the Docker data volume still exists.

 When mounting a volume, you do not need to specify the mount source but
specify a mount point. Docker generates a directory for each volume in the
"/var/lib/docker/volumes" directory as the mount source.

 If the mount point is an existing directory in the container, data in the

directory is copied to the volume.

 If the mount point is an empty directory in the container, the required

directory is automatically created.

 If you start the container to which a volume that does not exist is mounted,
Docker will automatically create a volume for the container.

 When a volume is used, you can set the volume permission of the container
to read-only by setting the "ro" parameter.

 For details about volumes, see https://docs.docker.com/storage/volumes/.

 Note: "/usr/local/apache2/htdocs" is the directory for storing static files in the
Apache server.

 Volume common commands:

 "docker volume create": Creat a volume.

 "docker volume ls": View the volume details.

 "docker volume rm": Delete a volume.

 You can also view the mounting information in the "proc/$$/mountinfo" file. $$
indicates the process ID.
 The Linux binding and mounting (bind mount) mechanism allows a directory or file
(not the entire device) to be mounted to a specified directory. Any operation
performed on the mount point occurs only on the mounted directory or file, and
content of the original mount point is hidden and not affected.

 Precautions:

 During the running of the container, the modified data in the bind mount
directory is saved. After the container is deleted, the data in the bind mount
still exists.

 The bind mount can mount a directory to a container or a file to a container.

You must specify the path of the directory or file, that is, the mount source,
and you must also specify a mount point, which limits the portability of
containers.

 If the bind mount is bound to a non-empty directory in the container, the

existing contents in the directory are hidden. If you do not want the entire
directory of the container to be overwritten, you can mount a file separately.

 If the file or directory where the mount source resides does not exist on the
host machine, the file or directory will be automatically created.

 During bind mount, you can set container's permission on the data to read-
only using the "ro" parameter. (After the "ro" parameter is set, the container
cannot modify the data, but the host machine still has the permission to
modify the data.)
 You can also use the "–v" parameter to store the data in Docker containers
persistently in bind mount mode.
 A volume container is a normal container with a volume mounted.
 Answers:

 ABCD

 F
 Technically, containers can be traced back to chroot in the early 1980s. In addition, key
technologies used in Docker, such as cgroups and namespace, are mature in Linux. As
early as 1982, the chroot technology implemented root file system switchover and
implemented limited file system isolation. In 2000, the pivot_root technology was
introduced to the Linux kernel version 2.3.41 to switch the Linux root file system,
avoiding security issues caused by chroot.
 The development of the container technology is as follows:
 Around 2000, some commercial container technologies appeared in the market,
such as Virtuozzo developed by Linux-VServer and SWsoft (now called Odin).
Although these technologies improved the performance greatly compared with
Xen and KVM at that time, they did not attract much attention in the market due
to various reasons. (Note that only container technologies on Linux OSs are
discussed in this course. Many well-known container technologies on non-Linux
platforms, such as jail of FreeBSD and Zone on Solaris, also appeared at the same
time.)
 In 2005, Odin released the OpenVZ technology based on the Virtuozzo
technology, and started to promote the core container technologies of OpenVZ to
the main line of the Linux kernel. At this time, IBM and other companies were also
promoting similar technologies. Finally, with the cooperation of the community,
the cgroup and namespace technologies have been formed, and the container
technology has gradually entered the public's view.
 As the container technology becomes gradually mature and well-developed in the
main line of the kernel, Docker emerged in 2013 attracted the attention of
technology companies and developers all over the world.
 Container is a sandbox technology that provides an isolated running environment
for applications.

 An application in a container is actually a process running on a host. An

isolated environment is created for the process using the namespace
technology, and available resources of the process are limited using the
cgroup technology. (A container is essentially a process with specified
parameters.)

 The namespace and cgroup features are the original features of the Linux
kernel.

 VMs use hypervisors to virtualize hardware resources, and the virtualized hardware
resources can be used to create VMs. VM OSs are installed to isolate resources.
Docker isolates resources by specifying the namespace parameter on the host OS
kernel.

 Application processes running in containers are managed by the OS of the host in

a unified manner, which is similar to the management of other processes on the
host. The only difference is that these isolated processes have extra configured
namespace parameters.

 Note: The picture is from the Docker official website.

 Namespaces are optional for creating a process in the Linux system.

 When a Docker container is created, a group of namespace parameters need to be

enabled for the process. With the namespace mechanism used for isolation, only
the resources, files, devices, status, or configurations specified in the current
namespace are visible to a container. In this way, the application running
environment is isolated.
 The user application in a container is actually the process whose PID value is 1 in
the container.

 The application in the container considers itself as the PID 1 process in the PID
namespace process (other processes in the host process space and processes in
other PID namespaces are invisible). Only the files and directories mounted in the
mount namespace can be viewed, and only the network devices in the network
namespace can be accessed. In conclusion, the container provides an isolated
environment for running of an application.

 During application running, the host does not have a container, which is only an
abstract concept. Docker creates an isolated environment for applications.

 Note: The process whose PID is 1 in the CentOS system is systemd.

 The /proc directory in Linux stores a series of special files that record the running
status of the current kernel. By accessing these files, you can view information
about the system and the running processes, such as the CPU usage and memory
usage.
 An application in a container is a common process in the host OS and competes
with other processes in the host OS for resource usage. Technical measures must
be taken to limit the resources that can be used by a process.

 Linux cgroups were launched by Google in 2006. Linux cgroups are an important
function in the Linux kernel for limiting process resources.

 There are multiple configuration files in the directory of each subsystem in the
cgroup. You can limit the corresponding resources using these configuration files.
For example:

 cpu type cgroup: Sets the CPU usage limit of a process.

 cpuset type cgroup: Allocates independent CPU cores and memory nodes for
processes.

 memory type cgroup: Sets the memory usage limit of a process.

 blkio type cgroup: Sets the block device I/O usage limit of a process.
 For details about the configurable parameters of the process CPU usage limit, see
the configuration file of the CPU subsystem in the cgroup directory: ll
/sys/fs/cgroup/cpu
 You can run the "dokcer search stress" command or visit the Docker Hub official
website to search for the pressure test image.
 Note: The "--cpu-shares" weight takes effect only when containers compete for
CPU resources.
 Docker creates a folder for each container in the "/sys/fs/cgroup/cpu/docker"
directory to limit the CPU resource usage. Each folder contains a group of CPU
resource limit files.

 Other resource subsystems, such as memory and blkio, create a folder for each
container in the directory to limit the usage of the corresponding resources.

 The preceding example shows that a running Docker container is an application

process that has multiple Linux namespaces enabled. The resources available to
the process are limited by the cgroup configuration.
 The memory resources that can be used by a container include the memory and
SWAP resources.
 Answers:

 F

 F

 The host has the permission. kill -9 pid

 A.
 Describe the differences between IaaS, PaaS, and SaaS from the service
perspective.
 What are the differences (in management scopes) between the traditional IT
architecture and IaaS, PaaS, and SaaS of cloud computing?
 Describe the differences between IaaS, PaaS, and SaaS from the perspective of
users.
 Challenge 1: Siloed Architecture Resulting in Difficulty in Sharing Resources
and Low Resource Utilization

 Static allocation and isolated management of resources: Departments are

often given physical machines (PMs) and virtual machines (VMs) that they
do not share with each other. This usually translates to resource
utilization in a data center of only 10% to 20%.

 Diverse application architectures: Business departments (collaborative

ISVs) independently select and purchase technical architectures and
middleware, resulting in different types of OSs or middleware in use.
 Challenge 2: Monolithic Application Architecture Cannot Support Agile & Fast
Delivery

 It can take months to introduce a new feature due to the huge baseline
code required and heavily dependent application architecture.
 Challenge 3: Separate Development (Dev) and O&M (Ops) and Incapability to
Achieve an E2E Automated Process

 End-to-end automation from coding to rollout cannot be implemented

due to separate development and O&M mode, resulting in low O&M
efficiency.
 Trend 1: Container Technologies Are Reconstructing PaaS

 Resources on VMs are isolated by Hypervisor.

 Containers provide isolated environments for processes and allow

multiple same processes to run on the same OS.
 Trend 2: Booming Development in Container Ecosystems Accelerates the
Development and Implementation of PaaS.
 Trend 3: Cloud Native Applications and Microservice Architecture

 Monolithic architecture has a quick start in the initial stage, which is not
good for subsequent scaling and code iteration.

 SOA is characterized by modularity and is still used by most large or

super-large companies.

 In the microservice architecture, an application is divided into multiple

small module systems. The architecture is flexible and easy to scale out. It
is suitable to application architectures that require fast iteration. However,
the microservice architecture is complex.
 Trend 4: Dev+Ops

 DevOps is a methodology that aims to break the department silos. In

other words, it aims to connect the development and test work in an
orderly manner and improve the speed and reliability of application
development, test, rollout, and iteration.
 Picture source: GitHub
 The advantage of this architecture is that the Swarm project is seamlessly
linked to Docker, and the Docker commands can be used to manage clusters.
 This architecture features a double-layer structure, high integration, and easy
to learn. However, it is difficult to locate faults due to high integration.

 Picture source: Docker official document

 Google launches more than 2 billion containers every week to provide services.
In the 1990s, Google started to use container technologies widely.

 Picture source: Mesos official document

 In addition, the Mesos architecture is loosely coupled and can be customized in
many aspects. Therefore, O&M personnel can develop modules as required.

 Mesos + Marathon is a solution provided by Mesos for the container

orchestration management platform.

 A scheduler of other frameworks may need to serve the entire cluster. While, a
scheduler of Mesos only needs to serve a smaller-scale cluster because the
scheduler at the first level allocates the entire node to a framework, and then
performs secondary scheduling in the framework. If there are multiple
frameworks, for example, if there are multiple Marathons, the scheduling can
be performed in parallel.

 Picture source: Mesos official document

 Disadvantages: Kubernetes has many logical objects and has high
requirements on the abilities of the learners.

 Orchestration: As service scenarios become more and more complex, a set of

service scenarios may contain dozens or hundreds of applications. The
microservice architecture aggravates this situation. Orchestration is the action
of processing the association between applications.
 The Kubernetes project architecture consists of two types of nodes: Master and
Node.

 The controller node is the Master, which consists of three independent

components that work closely together. The three components are as follows:
kube-apiserver: responsible for API services; kube-scheduler: responsible for
scheduling, and kube-controller-manager: responsible for container
orchestration. The persistent data of the entire cluster is processed by kube-
apiserver and then stored in etcd.

 The core of a compute node is a component called Kubelet. In the Kubernetes

project, Kubelet uses CRI to communication with container runtimes (for
example, Docker). In addition, Kubelet interacts with a plugin called device
plugin through gRPC to manage PMs. This is also a function that must be
focused on in work such as machine learning training and high-performance
job support based on the Kubernetes project. Another important function of
Kubelet is to invoke network plug-ins and storage plug-ins to configure
network and persistent storage for containers. The two interfaces are CNI and
CSI.
 The application creation logic of Kubernetes is as follows: First, describe the
application that you want to manage through an orchestration object, such as
a pod, job, and cron job. Then, define some service objects, such as service,
Secret, and Horizontal Pod Autoscaler (automated horizontal expansion), for
the application to implement specific platform-level functions.
 This method is called the declarative API of Kubernetes. The orchestration
objects and service objects corresponding to this API are API objects in the
Kubernetes project.
 From the perspective of the microservice architecture, services with multiple
independent functions bring overall flexibility, but also increase deployment
and O&M complexity. What features does Kubernetes implement? We can try
to understand it like the following: If we understand microservices as human
beings, service governance is actually communication between people. If there
are too many people, we need to optimize the living space and communication
mode, which requires clustering and orchestration. Docker Compose and
Swarm can solve the relationship between a few people and cannot solve
large-scale problems. Kubernetes is a highly abstraction of the business.
Kubernetes can know what kind of services are there, what characteristics (jobs,
cron jobs, autoscalers, StatefulSets, DaemonSets, etc.) are there in different
services, and what (ConfigMaps, Secrets, etc.) may be needed for
communication between different services. In this way, applications that are
closely related are deployed in the same pod, and applications in different
pods communicate with each other using Services. Deployments and
ReplicationControllers (RCs) can help applications quickly build services.
 Picture source: 3MS
 Application scheduling and resource management framework: sets up
Kubernetes-based enhanced automated lifecycle management, involving
application modeling, orchestration deployment, resource scheduling, auto
scaling, monitoring, and self-healing.

 Microservice operation and management framework: provides applications

with a series of distributed microservice management capabilities, such as
automated application registration, discovery, governance, isolation, and
invoking analysis, to simplify the complexity of distributed systems.

 Application development pipeline framework: streamlines the automated

CI/CD process from encoding and code submission to automated compilation,
packaging, continuous integration, as well as automated deployment and
rollout.

 Cloud middleware services: provide middleware services required by cloud-

based applications and integrate traditional non-cloud middleware capabilities
through service integration management.
 The PaaS platform provides the third-party application hosting function,
application management throughout its lifecycle from deployment to O&M, as
well as advanced O&M functions, such as auto scaling and affinity/anti-affinity,
to support quick application rollout.

 Picture source: 3MS

 Reference answer: Select Swarm for company A and Kubernetes for company
B.

 Swarm and Docker are seamlessly integrated. They apply to clusters with
a few nodes and are highly built-in. Clusters can run without
consideration in detail. However, it is difficult in customization,
debugging, and intervention.

 Mesos is suitable for ultra-large clusters, but it provides only a few

functions. It is a good scheduler but not an excellent container
orchestration platform.

 Kubernetes has multiple modules with rich functions and a loosely

coupled architecture. It is easy to customize and applies to large-scale
clusters. However, it has many abstract concepts and requires high
learning skills.
 Kubernetes is an open-source container scheduling platform across host clusters.
It can manage various underlying containers. It is similar to OpenStack, which
manages a large number of virtual nodes at the bottom layer to form a large
cluster to provide cloud services. Kubernetes provides a container-centric
architecture by managing the underlying container nodes and automating
deployment, scaling, and operations of application containers.
 The components can be queried using the command line interface (CLI).
 Functions of the Kubelet

 Mounts the data volumes required by pods.

 Downloads the secrets of pods.

 Runs containers in a pod through Docker or rkt.

 Periodically detects the container lifecycle.

 Reports the status of the pod back to the rest of the system by creating a
mirror pod if necessary.

 Reports the status of the node back to the rest of the system.
 The plug-ins involved in this course include Elasticsearch, Fluentd, and Kibana
(EFK).
 Why cannot I view the status of components such as kube-proxy?
 The master node has five pods.
 Is there only one system component (that is, kube-proxy) on the slave (worker)
nodes?
 Namespaces are ways to allocate cluster resources between multiple users (by
resource quota).
 Common namespaces

 Kube-system: The namespace for objects created by the Kubernetes system.

 Default: The default namespace for objects with no other namespace

 Using ReplicaSets and Deployments instead of ReplicationControllers is
recommended.
 "More functions" include the selector function.
 A complete application consists of multiple Deployments.
 A complete kubectl syntax does not necessarily contain all elements.
 Common values of flags include "-n=namespace" and "-o=wide".
 You are advised to use the YAML files to create objects.
 "create –f" indicates to create a resource from a file.

 You can replace the "create" command with the "apply" command.
 For details about the selector, see the following courses.
 Hyphens in front of some texts indicate the list format and cannot be ignored.
 You can replace the "scale" command with the "apply" command.
 You can replace the "rolling-update" command with the "apply" command.
 The new pod is deployed in the new ReplicaSet.
 The Deployment controller creates pods in the new ReplicaSet in sequence,
reduces the quantity of pods in the original ReplicaSet in sequence, and finally
replaces the original ReplicaSet with the new one, thereby implementing rolling
update of all pods.
 When creating the first Deployment, use nginx1.7.9. For subsequent Deployment
creation, use the other two YAML files to modify the Nginx version and perform
two rolling update operations to update the version to 1.8.1 and 1.9.1. When using
the "apply" command, record the two updates by adding the "—record"
parameter.
 Pay special attention to the information in red.
 The pod in the figure is a multi-container pod.
 Use single-container pods to avoid complex pod management.
 Pending: indicates that pods have been accepted by the Kubernetes system, but
one or more container images are yet to be created. The waiting time includes the
time for scheduling the pod and downloading the image using the network, which
may be long.

 Running: indicates that the pod has been bound to a node, and all containers in
the pod have been created. At least one container is running or is being started or
restarted.

 Succeeded: indicates that all containers in the pod are successfully terminated and
will not be restarted.

 Failed: indicates that all containers in the pod are terminated, and at least one of
them is terminated due to a failure. That is, the container exits in a non-0 state or
is terminated by the system.

 Unknown: indicates that the pod cannot be obtained due to certain reasons.
Generally, the reason is that the communication with the host where the pod is
located fails.
 The YAML file will be explained in the following sections.

 You can run the "kubectl explain pod.spec" command to view the detailed
parameters of YAML.
 The container name is defined in the YAML file.
 Parameters in the "NAME" column can be used to find the containers running in
the pod.
 Some pods are used to execute long-lived jobs, such as MySQL jobs and providing
file services. Some pods are used to execute one-off jobs and are closed after the
jobs are complete.
 Labels can map the organization architecture to the system architecture (like
Conway's law), which facilitates microservice management.
 Specify "Version:canary" to operate the first three pods during the rollout
operation. Specify "App:backend" to upgrade only the last three pods during the
upgrading operation.
 Do not use large-size, unmarked structured data in labels. Use annotations to
record such data.
 The label can be specified in the YAML file or added to the existing object by
running a command.
 An empty label selector (that is, a selector that has no mandatory conditions)
selects each object in the collection.

 A null label selector (only for optional selector fields) does not return any object.
 The key-value pairs time=2019 and time==2019 have the same meaning.
 The first half uses a set-based label selector, and the second half is an equality-
based label selector.
 The Kubectl command is case-sensitive.
 This slide and the next slide are actual examples of using labels and label selectors.
 The affinity scheduling function described on this slide will be described in detail in
the following sections. This slide uses the set-based selector as an example.
 How does Kubernetes implement this logical object?
 ClusterIP is the default mode. LoadBalancer requires additional plug-ins to provide
load balancing.
 The endpoint controller maintains the mapping between services and pods.

 The kube-proxy implements the service, that is, the access from the pod to the
service in Kubernetes and the access from the node port to the service out of
Kubernetes.
 The iptables mode is the default mode.
 The IPVS can be used only after being manually enabled.
 For details about the YAML file, see the description in the course of the pod
management and usage.
 The "targetPort" value is the same as the deployment port.
 The service named kubernetes is created by the system by default. Do not perform
any operation on the service.

 What is the service implementation type used in this test?

 kubeDNS is the default DNS component in Kubernetes.
 The "nslookup" command can be used to specify the query type, query the lifetime
of the DNS record, and specify the DNS server to be used for resolution.
 The complete path for accessing a service is "httpd-svc.default.svc.cluster.local"
 The headless service is mainly used for StatefulSet.
 The selector of the service must match the label of the pod. Note that the label is
not that of the deployment.
 To use a domain name to access the service, you need to perform operations in a
pod. If you use DNS to access the service out of the pod, the operation does not
take effect. As a result, you cannot access the service.
 DaemonSet ensures that pods run on all business nodes.
 This is for demonstration only. Generally, Nginx is not created using DaemonSet.
 How many DaemonSet replicas are there after the faulty node recovers?
 Job page is a kind of replica controller.
 During deployment, you can set restartPolicy to always.
You can run the logs command to view the job running result.
 Cron Job is not a kind of job.
 For details, see the crontab command syntax.
 Is a pod in the Running state normal?

 Running: indicates that the pod has been bound to a node, and all containers in
the pod have been created. At least one container is running or is being started or
restarted.
 If you want your container to be killed and restarted if a probe fails, specify a
liveness probe, and specify restartPolicy to Always or OnFailure.

 If you want to start sending traffic to a pod only when a probe succeeds, specify a
readiness probe. In this case, the readiness probe may be the same as the liveness
probe, but the existence of the readiness probe in the specifications means that
the pod will start without receiving any traffic and only start receiving traffic after
the probe succeeds.

 If a container needs to process large data, configuration files, or migration during

startup, use the readiness probe.

 If you want the container to be self-maintained, you can specify a readiness probe
that checks an endpoint specific to readiness that is different from the liveness
probe.
 If the status code is 404, the diagnosis fails.
 For readiness probes, if the diagnosis fails, rectify the fault using the restart policy.
 - touch: Indicates that a healthy file is written to the /tmp directory after the
container is created. It is used for probe detection.
 Run the describe command to view the pod details.
 By default, if the detection fails for three times, the container is considered not
alive. If the detection succeeds for one time, the container is considered alive. The
default value can be changed.
 These parameters can be set in the probe section of the YAML file.
 Liveness containers are in the alive state within the first 10 seconds. The status
code 200 is returned, and then the status code 500 is returned.
 When the probe detects that the port cannot be accessed, a failure message is
returned.
 The liveness probe and readiness probe are implemented in a similar manner, but
are processed in different ways.
 The two types of probes adopt different processing methods when a detection
fails.
 This slide and the last two slides provide a complete detection experiment.
 In this slide, a fault is simulated to enable the probe detection to fail.
 This fault can be recovered by restoring the file. Is there any other convenient
method?
 The Kubernetes network model is designed to meet the preceding communication
requirements.
 As shown in the communication between Pod N and Pod M in the above figure,
this network is also known as a pod network.

 Each node running the pod also has an IP address on the plane network through a
bridge device or other devices, such as the cbr0 interface in the above figure,
which means that the communication between the node and the pod can also be
directly performed on the network.
 The specific network address to be used needs to be specified using the "service-
cluster-ip-range" option when kube-apiserver is started.

 The "service-cluster-ip-range" option can specify the subnet, for example,

10.96.0.012.

 Each service object has a fixed IP address called a cluster IP address on the
network. If an administrator or user needs to create or modify a service object, the
API server stores the operation and triggers kube-proxy on each node to define
the service object as iptables or IPVS rules based on the proxy modes of the
nodes. In this way, packets are forwarded between the cluster IP address and pod
IP address of the service.
 Traffic outside the cluster is directed to a pod object based on the following
information about the node where the pod resides: host port, node port and host
network, and node port and service objects of the load balancing type working at
the cluster level.
 After the service is created, all nodes can provide specified pod services externally
through this port.
 Multiplexing can be implemented in two modes:

 The MAC VLAN configures a MAC address for each virtual interface and
sends and receives layer 2 packets based on the MAC address. The IP VLAN
sends and receives layer 2 packets based on an IP address and uses a single
MAC address, making the IP VLAN more suitable for VMs.
 The container management system and network plug-ins communicate with each
other using JSON files to implement the network functions of containers. Specific
work is implemented by plug-ins, including creating the container nets, associating
a network interface with the corresponding nets, and allocating an IP address to
the network interface.
 VXLAN: The Flannel backend uses the VXLAN module in the system kernel to
encapsulate packets and uses the tunnel forwarding mechanism to implement
inter-node pod communication. This is the mainstream mode of Flannel.

 The Linux kernel supports VXLAN since Linux 3.70.

 host-gw: It is also called Host Gate Way. A route to the destination container
address is created on the node to directly forward packets.

 The host-gw mode requires that all nodes must be on the same layer 2
network. Therefore, this mode does not apply to large-scale networks. The
host-gw mode provides good forwarding performance and is easy to set.
Therefore, it is recommended in scenarios that require high packet
forwarding performance.

 UDP: It is encapsulated using common UDP packets for tunnel forwarding, which
provides low performance. This mode is used only when the first two modes are
not supported.

 In addition to these three backends, Flannel supports AliVPC, AWS VPC, Alc, and
GCE in the exercise.
 network: Network address in CIDR format used by the Flannel to configure
network functions for pods.

 SubnetLen: length of the mask that is used for dividing a network into subnets for
each node. The default length is 24 bits.

 SubnetMin: used for specifying the minimum address segment on a subnet that
can be allocated to the subnet. For example, you can limit the address segment on
a subnet to 10.244.10.0/24. In this way, 0 to 9 are not used.

 SubnetMax: used for specifying the minimum address segment on a subnet that
can be allocated to the subnet, for example, 10.244.100.0/24.

 Backend: VXlan, host-gw, and UDP (slowest)

 In most cases, a user wants to create a logical network subnet across multiple L2
or L3 networks. This is implemented by using the overlay encapsulation protocol.
(The most common protocol is VXLAN, which encapsulates the overlay traffic into
UDP data packets.)

 However, due to the lack of standardization of the controller plane, VXLAN may
cause a higher cost, and multiple VXLAN networks from different vendors usually
cannot communicate with each other. Each vendor has its own SDN controller to
create and manage VXLAN tunnels.

 In addition, Kubernetes uses iptables and NAT to intercept the traffic entering the
logical/virtual address and route the traffic to the proper physical destination.

 The VLAN technology also solves the problem of L2 network broadcast domain
division and provides multi-tenant support. With the broadcast domain division by
the VXLAN technology, tenants can independently establish networks and
communicate with each other.
 The VXLAN direct routing backend forwarding mode has advantages of both the
VXLAN backend and host-gw backend, ensuring transmission performance and
packet forwarding across L2 networks.
 Containers are not affected by backend storage systems of volumes. Volumes only
function as a catalog for containers.
 For more information, visit https://kubernetes.io/docs/concepts/storage/volumes/.
 EmptyDir is a convenient but insecure temporary storage solution.
 EmptyDir corresponds to a real Dir directory on the node.
 The "df –h" command is used to view the storage capacity of the node where pod
resides.
 HostPath reduces the flexibility of pod deployment because it restricts the nodes
where pods can be deployed. Generally, this mode is not used.
 Before using the HostPath, check whether object resources exist on the node.
 PVs and PVCs are the most common storage modes.
 You can create PVs and PVCs in any sequence. You are advised to delete PVCs
before deleting PVs.
 Only the PV in the Available state can be associated with a PVC. The PV in the
Released state cannot be associated with a PVC.
 You can run the "kubectl edit" command to modify the existing PV.
 Actually, the three matching mechanisms are essentially the same, that is, a proper
PV is filtered out based on filtering criteria.
 In this exercise, the StorageClass is used for filtering out the proper PV.
 AWS EBS, Cinder, and Ceph RBD provide their own provisioners. Therefore, you do
not need to create provisioners when using these types of backend storage.
 Containers are not affected by backend storage systems of volumes. Volumes only
function as a catalog for containers.
 Different ConfigMaps with the same pod template can run properly in different
environments.
 In this case, the content in ConfigMap is used as an example only.
 You can run the “describe” command to check whether the content of
ConfigMap game-config-3 is the same as that of game-config created using the
directory.
 The command saves two pieces of data. The first key is special.how, and the value
is very. The second key is special.type, and the value is charm.
 How many pieces of data are saved in this experiment? What are the keys?
 What fields in the env and envFrom fields are used to create these environment
variables?
 The number of data records is determined when the ConfigMap is created.
 ConfigMap is checked when a pod is created.
 Secret is more secure than ConfigMap, but is not absolutely secure. Data may still
be detected.
 The Secrets created by the preceding two commands are different.
 Base64 encoding can be decoded, and therefore is not an absolute secure manner.
 If data is not encoded using Base64 when being written to the YAML file, an
incorrect value is obtained after decoding when pod uses Secret.
 The pod automatically decodes the Secret content.
 This method does not transfer the complete secret content.
 Stateless
 Stateful
 Stateful applications are usually bound to fixed storage devices. When users access
stateful applications, traffic is forwarded to specific pods.
 The method of creating a PVC is different from that described in the preceding
sections. For details, see HCIP-Cloud Computing-Container V1.0 Lab Guide.
 The label selector of the headless service must be the same as the label of the pod.
Note that it must be different from the label of the StatefulSet.
 If the PVCs fail to be created, no pod is created.
 For details about how to compile the YAML file of the headless service, see section
"Service Discovery“ in HCIP-Cloud Computing-Container V1.0 Lab Guide.
 You must run the nslookup command in the pod.
 If the StatefulSet is faulty, the pod needs to be automatically rebuilt and the status
is not lost.
 When you delete a StatefulSet application, the pod is deleted at the same time. To
delete pods in sequence and gracefully, you can reduce the StatefulSet capacity to
0 and then delete it.
 Even if the parallel pod management policy is used, the StatefulSet and
Deployment are different.
 QoS: Quality of Service QoS
 Kubernetes manages pods, in which the compute resources are the most
important. Therefore, most resource management is based on CPUs and memory.
 Memory and hard disks can be compressed in virtualization scenarios, but cannot
be compressed in Kubernetes of the current version.
 The "-o yaml" command is used to display node information. The command
output is in the YAML format.
 OOM: out of memory
 The pod with a lower priority is killed first when resources are insufficient.
 Burstable

 When resources are available, the pod runs at the optimal performance. When
resources are insufficient, the pod runs with the minimum quantity of resources.
 This pod is also known as the "best-effort" pod that uses the resources as much as
they can.
 If the usage of uncompressible resources (memory) exceeds the limit, OOMKilled is
triggered to kill the pod. If the usage of compressible resources exceeds the limit,
the pod will not be killed.
 This problem occurs because the memory fails to be scheduled and the pod
cannot be created.
 "capacity" indicates the actual quantity of resources on this node. For example,
if this host has 4 vCPUs and 8 GB memory, then under the "capacity" field, the
value of "cpu" is "4" and the value of "memory" is 8 GB (the unit of the memory
is Ki).

 "allocatable" indicates the quantity of resources that can be used by the

container on this host, that is, the remaining resources after the occupied
resources on the node are excluded. As shown in the figure, the value of
"allocatable" is less than that of "capacity".
 cAdvisor is an open-source container monitoring project of Google. It can
monitor resources and containers on the node in real time and collect
performance data, including the CPU and memory usage, network throughput,
and file system usage. Kubernetes has embedded cAdvisor as a submodule
into the kubelet. When the kubelet is started, the cAdvisor is also started.
 To ensure the stability of physical nodes and the stable running of daemon
programs, a resource protection mechanism, that is, eviction, must be
introduced.
 These default thresholds are written to the kubelet configuration file during
installation. Modify them only when necessary.

 You can run the kubelet command to modify these parameters.

 The data used by the kubelet to calculate the eviction thresholds is based on
the value read by control groups (cgroups) and the data monitored by
cAdvisor.
 When the eviction action occurs, the QoS rule is referenced first. When the QoS
rules are the same, it is removed based on the priority.
 Kubernetes-scheduler filtering process: Nodes that do not meet the filter
criteria are deleted first. Then, the best node is selected based on the filter
criteria and the node with the highest priority is selected. If the priority has the
highest weight, select a node randomly. For example, if the filter criteria are
that the free memory of a node is at least 4 GB, and the free memory of three
nodes is 4 GB, 8 GB, and 8 GB respectively, the node of 8 GB has a higher
priority.
 In the first step, the default scheduler first invokes a group of scheduling
algorithms called Predicate to check each node. In the second step, it is scored
by using a group of scheduling algorithms called Priority.
 10 indicates that a node is suitable, and 0 indicates that a node is not suitable.

 Picture source: Kubernetes community

 The following is an example of LeastRequestedPriority: If the available CPU
resource is 100 and the resource applied for running containers is 15, the CPU
score is 8.5. If the available memory resource is 100 and the resource applied
for running containers is 20, the memory score is 8.

 The score of the evaluation rule on this node is [(100-15) x 10/100 + (100-20) x
10/100]/2=8.25.
 A service account is required to verify the login of the Dashboard pod by
Kubernetes.
 Resource objects cannot be searched in the search box, for example, Pod.
 If heapster and influxdb are not configured, the metric information of pods cannot
be obtained.

 Resource objects in Succeeded or Running state are displayed in green. Resources

in Pending state are displayed in orange. Resource objects in Failed or Unknown
state are displayed in red.
 If heapster and influxdb are not configured, the metric information of Pod cannot
be obtained.
 You can adjust the format of the log output window in the upper right corner of
the window. The logs have been downloaded to the local computer.
 You can adjust the format of the log output window in the upper right corner of
the window. The logs have been downloaded to the local computer.
 Answers:

 BCD

 F
 The differences between the Helm and Linux Yum package management tools
are as follows: Yum manages the dependency between installation packages.
With Yum, you do not need to solve the dependency issue between internal
components of the software when installing the software on a Linux OS such as
CentOS. With Helm, the scattered resource distribution during application
orchestration is solved.
 Picture source: Helm official website
 "name": name of the current chart, which is mandatory

 "version": version number, which is mandatory

 "description": single-statement description of the current project, which is

optional

 "keywords": keyword list of the current project, which is optional

 "sources": URLs of source codes used in the current project, which is

optional

 "home": URL of the home page of the current project, which is optional

 "maintainers": project maintainer information, including the name, email,

and URL attributes. This parameter is optional.
 In actual scenarios, an application usually consists of multiple parts. For
example, the production environment of a website can include the MySQL
database, Tomcat displayed on the frontend, and Redis cached on the backend.
These parts are mutually dependent.
 Templates are the most important part of a chart and the most powerful part
of Helm. Templates use standardized parameters for configuring charts and
allow users to customize applications using the "values.yaml" file. Templates
improve the flexibility of application deployment and apply to different
environments.
 A chart or release is an object whose parameter value can be obtained
according to the attribute value of the object.
 randAlphaNum, b64enc, and quote are all functions supported by the Go
template language. These functions can be connected through a pipe
(represented by |). "{{randAlphaNum 10 | b64enc | quote}}" indicates that a
character string whose length is 10 is generated randomly, the string is
encoded in Base64 mode, and then double quotation marks are added to both
sides of the string.
 RBAC is a default authorization plug-in of the new Kubernetes version.
 Kubernetes uses the microservice architecture. The API server, that is, the API
gateway, is the entry of the entire architecture. All accesses must pass through
the API server.
 All Kubernetes clusters have two categories of users: user accounts (human,
not managed by Kubernetes) and service accounts (pods, managed by
Kubernetes).

 Authentication

 Authorization

 Admission control
 User : Role = 1 : N

 Role : Permission = 1 : N
 Group permissions can be inherited by all users in the group. This feature is the
same as that of Windows.
 Configure the context so that you can use kubectl to switch to the user directly.
 The "ImagePullSecrets" parameter is the secret object used for verification
when the pod pulls images from the private image repository.
 etcd is the key-value database of Kubernetes. For details about the secret
objects, see the corresponding course.
 RBAC is a stable feature from Kubernetes 1.8 and officially becomes the default
authorization plug-in of Kubernetes.
 Note: A role is used only in the namespace scope it defines.
 Note: ClusterRole applies to clusters.
 A RoleBinding can be used to bind a role to one or a group of users, or assign
a ClusterRole to one or a group of users.
 RoleBindings can be used to bind roles and users (including user accounts and
service accounts) in a unified namespace. In this case, users have the rights
assigned to the roles in the namespace.

 RoleBindings can be used to bind ClusterRoles and users (including service

accounts). In this case, users only act on the pod resources in the current
namespace. The advantage is that a unified ClusterRole can be created and the
same permission can be assigned to subjects in different namespaces. You do
not need to create a role for each namespace. In the actual production
environment, this method is often used to bind a read-only role to the default
service account of all namespaces.

 ClusterRoleBindings can be used to bind ClusterRoles and users (including user

accounts and service accounts). In this case, users can obtain the
corresponding permissions of resources in the cluster.

 ClusterRoleBindings cannot be used to bind roles and users because its

metadata does not contain the namespace attribute.
 Tip: Check whether the secret object called by the pod is the same as that of
the service account which is named "default" in the namespace by running the
"kubectl describe pod XXXX" command.

 Answer: If the service account is not defined when the pod is created, the
system allocates a service account named "default" to the pod. The default
service account has most permissions to access the API server.
 The Docker JSON logging driver can be regarded as a logging driver that is
only responsible for collecting logs, but provides continuous output streams
without separators. This makes the logs hard to be identified after being
exported directly. Therefore, tools such as logrotate are required for processing
the logs (for example, splitting, compressing, and deleting old log files).

 Picture source: Kubernetes official website

 Currently, if other system mechanisms are used to split logs, the "kubectl logs"
command can be used to query only the latest log content. For example, if a 10
MB file is split into two files using the logrotate function, a 10 MB file and an
empty file are generated. In this case, no command output is displayed for
"kubectl logs".
 Picture source: Kubernetes official website
 Picture source: Kubernetes official website
 Note: In this solution, two identical logs exist on the host, in which one is
written by the applications and the other is the JSON file for stdout and stderr
of the sidecar container. Therefore, this solution causes a waste of disk space.
Therefore, you are advised to use the preceding solution unless there is no
alternative.

 Picture source: Kubernetes official website

 Note: In the sidecar container, the logging agent is simple to deploy and is
friendly to the host. However, the sidecar container may consume many
resources or even break down the application container. In addition, no log is
displayed after you run the "kubectl logs" command because logs are not
exported to stdout.

 Picture source: Kubernetes official website

 Picture source: Kubernetes official website
 Picture source: Kubernetes official website
 Heapster is a monitoring project under the Kubernetes project.

 Weave Scope is a monitoring project developed by Weaveworks.

 Prometheus is the second most popular project in CNCF.

 Picture source: Heapster project official website
 The Prometheus project, like the Kubernetes project, comes from the Borg
system of Google. Its prototype system is BorgMon, which is an internal
monitoring system that is developed almost at the same time as Borg. The
object of Prometheus is similar to that of Kubernetes, which is to deliver the
design concept of Google's internal system to users and developers in a more
user-friendly manner.

 SRE is the practitioner of DevOps. Its work contents and responsibilities are
similar to those of traditional O&M engineers. The difference is that SRE
adopts automation tools and monitoring tools and therefore is more automatic
and efficient.
 The core of Prometheus is to collect the metrics of monitored objects in Pull
mode, and then save the data in a time series database (TSDB) such as
OpenTSDB and InfluxDB for later retrieval by time.

 With this core monitoring mechanism, the remaining components of

Prometheus are used to cooperate with this mechanism. For example,
Pushgateway allows monitored objects to push metrics to Prometheus.
Aletmanager can flexibly set alarms based on the metrics.

 Picture source: Prometheus official website

 The container-related metrics are mainly from the built-in cAdvisor of Kubelet.
After Kubelet is started, cAdvisor is also started. The information provided by
cAdvisor can be detailed to the usages of the CPU, file system, memory, and
network resources of each container.