深度探索：Kubernetes管理设计模式与Docker、CoreOS及多平台实践

5星 · 超过95%的资源需积分: 15 154 浏览量更新于2024-07-20 3 收藏 29.88MB PDF 举报

《Kubernetes管理设计模式：与Docker、CoreOS Linux及其他平台》是一本深入探讨在容器集群管理中应用最佳实践的书籍，由Deepak Vohra撰写。该书针对已有基础的Linux管理员、CoreOS管理员、应用开发者以及容器即服务（CAAS）开发者，讲解如何在Docker和CoreOS Linux等平台上有效地使用Kubernetes进行高级管理。主要内容包括以下几个方面： 1. Kubernetes基础知识：介绍Kubernetes作为容器集群经理的地位，它是基于Docker的开源项目，自2014年开源以来得到了广泛应用。书中特别强调了CoreOS Linux的优势，由于其预装了Docker且支持多种云提供商（如AWS和Google Cloud Platform），以及虚拟化平台，它成为本书的核心平台之一。 2. 容器与Pod：Kubernetes的基本单元是Pod，它是包含一组共享文件系统和网络的容器集合。Pod的抽象概念类似于面向对象设计模式，使得容器化应用程序的设计更加模块化和可复用。 3. 平台与配置：章节涵盖了在AWS、CoreOS on AWS、CentOS with OpenShift、Debian 8（jessie）在AWS和Google Container Engine上的Kubernetes应用。书中介绍了如何在多云环境中工作，使用Ansible等工具，并讨论了Kubernetes的PaaS平台OpenShift。 4. 管理与设计模式：重点讲述了配置管理设计模式，如ConfigMaps用于存储配置数据，Autoscaling实现自动伸缩，弹性资源使用，以及高可用性设计。此外，还涉及了日志管理、调度策略、滚动更新、卷管理、服务类型和跨多个云提供商区域部署。 5. 高级功能：涵盖了创建高可用网站、构建高可用Kubernetes主节点集群，以及使用卷、配置映射、服务、自动扩展和滚动更新等高级特性。计算资源管理和调度技术也进行了深入剖析。 6. 实践操作：通过实例演示如何在CoreOS上搭建Kubernetes集群，利用AWS等多个环境，并逐步应用所学知识，如配置多区域、使用Tectonic Console、以及开发高度可用的应用程序。《Kubernetes管理设计模式：与Docker、CoreOS Linux及其他平台》为读者提供了一个全面的学习框架，帮助他们掌握Kubernetes的高级管理技术，适用于各种Linux和Docker背景的读者，适合希望通过这本书深入了解和实践容器化应用的管理。

xvii

Introduction

Docker was made available as open source in March 2013 and has become the most commonly used

containerization platform. Kubernetes was open-sourced in June 2014 and has become the most widely

used container cluster manager. The first stable version of CoreOS Linux was made available in July 2014

and since has become the most commonly used operating system for containers. My first book, Kubernetes

Microservices with Docker (Apress, 2016), is an introduction to creating microservices with Kubernetes and

Docker. This book, Kubernetes Management Design Patterns, takes container cluster management to the next

level and discusses all or most aspects of administering and configuring Kubernetes on CoreOS and applying

suitable design patterns such as ConfigMaps, autoscaling, resource quotas, and high availability. Kubernetes

is a cluster manager for Docker and rkt containers, but this book discusses Kubernetes in the context of

Docker only. A cluster manager for Docker containers is needed because the Docker engine by itself lacks

some functionality, such as the ability to scale a cluster of containers, schedule pods on nodes, or mount a

certain type of storage (such as an AWS Volume or Github repo) as volumes. Docker Engine 1.12 integrates the

Docker Swarm cluster manager and Docker Swarm does overcome some of the earlier limitations of Docker

by providing replication, load balancing, fault tolerance, and service discovery, but Kubernetes provides

some features suitable for developing object-oriented applications. The Pod abstraction is the atomic unit of

deployment in Kubernetes. A Pod may consist of one or more containers. Co-locating containers has several

advantages as containers in a Pod share the same networking and filesystem and run on the same node.

Docker Swarm does not support autoscaling directly. While Docker Swarm is Docker native, Kubernetes is

more production-ready having been used in production at Google for more than 15 years.

Kubernetes Design Patterns

A software design pattern is a general reusable solution to a commonly occurring problem

within a given context in software design.

Wikepedia

A Docker image includes instructions to package all the required software and dependencies, set the

environment variables, and run commands, and it is a reusable encapsulation of software for modular

design. The atomic unit of modular container service in Kubernetes is a pod, which is a group of containers

with a common filesystem and networking. The Kubernetes pod abstraction enables design patterns for

containerized applications similar to object oriented design patterns. Pod, service, replication controller,

deployment, and ConfigMap are all types of Kubernetes objects. Further, because containers interact with

each other over HTTP, making use of a commonly available data format such as JSON, Kubernetes design

patterns are language and platform independent. Containers provide some of the same benefits as software

objects such as modularity or packaging, abstraction and reuse. Kubernetes has described three classes or

types of patterns.

• Management design patterns

• Patterns involving multiple cooperating containers running on the same node

• Patterns involving containers running across multiple nodes

Some of the benefits of modular containers are as follows:

• The container boundary is an encapsulation or abstraction boundary that can be

used to build modular, reusable components.

• The reusable containers may be shared between different applications and agile

developer teams.

• Containers speed application development.

• Containers are suitable for agile team development.

• Containers can be used to encapsulate a best design or implementation.

• Containers provide separation of concerns

The design patterns are introduced in the publication Design Patterns For Container-Based Distributed

Systems, by Brendan Burns and David Oppenheimer (https://www.usenix.org/node/196347). In this book

we shall be using some of these and other design patterns.

Kubernetes Architecture

A Kubernetes cluster consists of a single master node (unless a high-availability master is used, which is not

the default) and one or more worker nodes with Docker installed on each node. The following components

run on each master node:

– etcd to store the persistent state of the master including all configuration data.

A high-availability etcd cluster can also be used.

– An API Server to serve up the Kubernetes REST API for Kubernetes objects (pods,

services, replication controllers, and others).

– Scheduler to bind unassigned pods on nodes.

– Controller manager performs all cluster level operations such as create and update

service endpoints, discover, manage and monitor nodes. The replication controller

is used to scale pods in a cluster.

The following components are run on each worker node:

– kubelet to manage the pods (including containers), Docker images, and volumes.

The kubelet is managed from the API Server on the master node.

– kube-proxy is a network proxy and load balancer to serve up services.

The Kubernetes architecture is shown in FigureI-1.

■ INTRODUCTION

xviii

xix

■ INTRODUCTION

Why CoreOS?

CoreOS is the most widely used Linux OS designed for containers, not just Docker containers but also rkt (an

implementation of the APP Container spec) containers. Docker and rkt are pre-installed on CoreOS

out-of-the-box. CoreOS supports most cloud providers including Amazon Web Services (AWS) Elastic

Compute Cloud (EC2), Google Cloud Platform, and virtualization platforms such as VMWare and VirtualBox.

CoreOS provides Cloud-Config for declaratively configuring for OS items such as network configuration

(flannel), storage (etcd), and user accounts. CoreOS provides a production-level infrastructure for

containerized applications including automation, security and scalability. CoreOS has been leading the drive

for container industry standards and in fact founded appc. CoreOS is not only the most widely used operating

system for containers but also the most advanced container registry, Quay. CoreOS provides server security

with Distributed Trusted Computing. CoreOS also provides Tectonic Enterprise for enterprise-level workloads

without operational overhead and an out-of-the-box Kubernetes cluster and a user-friendly dashboard.

Chapter Description

In Chapter 1 we shall install Kubernetes on Amazon Web Services (AWS), create a sample deployment

and service, and subsequently invoke the service. Kubernetes installation on AWS requires almost no

configuration to spin-up a multi-node cluster.

In Chapter 2 we shall install Kubernetes on CoreOS, which is the main platform we shall use for most of

the chapters. We’ll first create an AWS EC2 instance from Amazon Linux AMI, which has the AWS Command

Line Interface (CLI) preinstalled. We’ll then SSH log in to the EC2 instance and install Kube-aws. Then we

will launch a CloudFormation for a Kubernetes cluster with one controller node and three worker nodes and

SSH log in to the controller instance and install kubectl binaries to access the API server.

kubectl

Docke

API Server (pods,

services, replication

controllers)

Scheduler

Master Node

Pods

Containers

Worker

Node

kubelet kubeletproxy proxy

Worker

Node

etcd Storage

Controller Manager

Figure I-1. Kubernetes Architecture

■ INTRODUCTION

In Chapter 3 we shall discuss Google Cloud Platform for Kubernetes. First, create a project and a

VM instance. Subsequently connect to the VM instance to create a Kubernetes cluster and test a sample

application.

In Chapter 4 we shall use multiple zones to create an AWS CloudFormation for a Kubernetes cluster.

Chapter 5 introduces the Tectonic Console for managing Kubernetes applications deployed on CoreOS.

Chapter 6 is on volumes. We demonstrate using volumes with two types of volumes:

awsElasticBlockStore volume and gitRepo volume.

Chapter 7 is on using services. We shall create sample services for three kinds of services supported by

Kubernetes: ClusterIP, NodePort and LoadBalancer.

In Chapter 8 we shall discuss rolling updates. A rolling update is the mechanism by which a running

replication controller can be updated to a newer image or specification while it is running.

In Chapter 9 we introduce the scheduling policy used by Kubernetes to schedule pods on nodes. We

discuss the various options including using a NodeSelector, and setting node affinity.

Chapter 10 is on allocating compute resources to applications. The two supported compute resources

are CPU and memory. We shall discuss setting resource requests and limits and also how Kubernetes

provides a quality of service by guaranteeing a preset level of resources.

Chapter 11 is on ConfigMaps, which are maps of configuration properties that may be used in pods and

replication controller definition files to set environment variables, command arguments and such.

Chapter 12 is on setting resource quotas on namespaces for constraining resource usage in a

namespace. Resource quotas are useful in team development (different teams have different requirements)

and different phases of application which have different resource requirements such as development,

testing, and production.

Chapter 13 is on autoscaling, which is suitable for production workloads that can fluctuate. Autoscaling

of a deployment, replica set, or replication controller scales the number of pods in a cluster automatically

when the load fluctuates.

Chapter 14 is on logging. The default logger is discussed in addition to cluster-level logging using

Elasticsearch, Fluentd, and Kibana.

In Chapter 15 OpenShift, a PaaS platform for Kubernetes, is discussed to create a high availability

master Kubernetes cluster using Ansible. Ansible is an automation platform for application deployment,

configuration management, and orchestration.

In Chapter 16 a high availability web site is developed using AWS Route 53 for DNS failover.

剩余409页未读，继续阅读

ramissue

粉丝: 354
资源: 1487

深度探索：Kubernetes管理设计模式与Docker、CoreOS及多平台实践

Kubernetes管理设计模式：Docker、CoreOS与多平台实战

标题：设计模式在七种开发语言中的应用

《Alexander.Shvets.Design.Patterns》：简化理解的OO设计模式精华

Kubernetes Management Design Patterns With Docker

Kubernetes Management Design Patterns.pdf

Kubernetes Management Design Patterns: With Docker, CoreOS Linux, and Other

Docker Management Design Patterns

Docker Management Design Patterns Swarm Mode on Amazon Web Services 无水印pdf

Docker Management Design Patterns Swarm Mode on Amazon Web Services 无水印原版pdf

Kubernetes Management Design Patterns(Apress,2017)

最新资源