设计云原生应用：Kubernetes模式与ServiceMesh实践

需积分: 16 17 浏览量更新于2024-07-15 收藏 4.02MB PDF 举报

《Kubernetes Patterns》是一本由O'Reilly Media出版的专业书籍，专为设计和构建云原生应用提供可重用元素和最佳实践。这本书探讨了Kubernetes的核心概念，这是一种容器编排平台，旨在简化应用部署、扩展和管理。作者BilginIbryam与RolandHuß在书中分享了他们在设计和操作云环境中云原生应用程序时积累的经验和模式。 ServiceMesher社区是一个致力于推动ServiceMesh（一种专注于服务之间通信管理的架构）在中国发展的开源社区。成立于2018年，它聚集了一群志同道合的志愿者，关注领域包括容器、微服务、Serverless等技术，并强调开源和云原生的理念。社区的目标是传播ServiceMesh技术，促进社区交流，并帮助企业采用这一技术。社区通过线上线下活动，如ServiceMesh Meetup，与蚂蚁金服和CNCF官方合作，定期举行技术沙龙，分享最新的实践和解决方案。蚂蚁金服作为ServiceMesh领域的积极探索者，其内部的ServiceMesh方案已成功应用于核心业务，并正大规模推广至全站。加入蚂蚁金服的ServiceMesh技术团队，候选人需具备以下技能和特质： 1. 至少熟悉Java或Golang中的一种语言，这是开发基础。 2. 精通云原生技术，特别是Kubernetes，以及CoreDNS、KNative、Istio或Linkerd等服务网格工具，对其中一项有深入理解。 3. 拥有网络编程经验，尤其是网络框架开发者，这在服务网格环境中至关重要。 4. 具备技术热情，善于学习新知识，对新技术充满好奇，具备强大的问题分析和解决能力，同时具备良好的团队协作、沟通和抗压能力。如果你符合这些条件并对此职位感兴趣，可以通过简历投递或直接联系社区了解更多信息，参与到蚂蚁金服的ServiceMesh实践中，推动企业架构向云原生的转型。

1 Christopher Alexander and his team defined the original meaning in the context of architecture as follows:

“Each pattern describes a problem which occurs over and over again in our environment, and then describes

the core of the solution to that problem, in such a way that you can use this solution a million times over,

without ever doing it the same way twice.” (A Pattern Language, Christopher Alexander et al., 1977, p. x). We

think this definition works for the patterns we describe in this book, except that we probably don’t have as

much variability in our solutions.

Design Patterns

The concept of design patterns dates back to the 1970s and from the field of architec‐

ture. Christopher Alexander, an architect and system theorist, and his team published

the groundbreaking A Pattern Language (Oxford University Press) in 1977, which

describes architectural patterns for creating towns, buildings, and other construction

projects. Sometime later this idea was adopted by the newly formed software indus‐

try. The most famous book in this area is Design Patterns—Elements of Reusable

Object-Oriented

Soware by Erich Gamma, Richard Helm, Ralph Johnson, and John

Vlissides—the Gang of Four (Addison-Wesley). When we talk about the famous Sin‐

gleton, Factories, or Delegation patterns, it’s because of this defining work. Many

other great pattern books have been written since then for various fields with differ‐

ent levels of granularity, like Enterprise Integration Patterns by Gregor Hohpe and

Bobby Woolf (Addison-Wesley) or Patterns of Enterprise Application Architecture by

Martin Fowler (Addison-Wesley).

In short, a pattern describes a repeatable solution to a problem.

It is different from a

recipe because instead of giving step-by-step instructions to solving a problem, a pat‐

tern provides a blueprint for solving a whole class of similar problems. For example,

the Alexandrian pattern “Beer Hall” describes how public drinking halls should be

constructed where “strangers and friends are drinking companions” and not “anchors

of the lonely.” All halls built after this pattern look different, but share common char‐

acteristics such as open alcoves for groups of four to eight and a place where a hun‐

dred people can meet with beverages, music, and other activities.

However, a pattern does more than provide a solution. It is also about forming a lan‐

guage. The unique pattern names form a dense, noun-centric language in which each

pattern carries a unique name. When this language is established, these names auto‐

matically evoke similar mental representations when people speak about these pat‐

terns. For example, when we talk about a table, anyone speaking English assumes we

are talking about a piece of wood with four legs and a top on which you can put

things. The same thing happens in software engineering when we talk about a “fac‐

tory.” In an object-oriented programming language context, we immediately associate

with a “factory” an object that produces other objects. Because we immediately know

the solution behind the pattern, we can move on to tackle yet unsolved problems.

xii | Preface

• Part II, Behavioral Patterns, describes patterns that sit on top of the foundational

patterns and add finer-grained concepts for managing various types of container

and platform interactions.

•

Part III, Structural Patterns, contains patterns related to organizing containers

within a Pod, which is the atom of the Kubernetes platform.

• Part IV, Conguration Patterns, gives insight into the various ways application

configuration can be handled in Kubernetes. These are very granular patterns,

including concrete recipes for connecting applications to their configuration.

• Part V, Advanced Patterns, is a collection of advanced concepts, such as how the

platform itself can be extended or how to build container images directly within

the cluster.

A pattern might not always fit into one category alone. Depending on the context, the

same pattern might fit into several categories. Every pattern chapter is self-contained,

and you can read chapters in isolation and in any order.

Who This Book Is For

This book is for developers who want to design and develop cloud-native applications

for the Kubernetes platform. It is most suitable for readers who have some basic

familiarity with containers and Kubernetes concepts, and want to take it to the next

level. However, you don’t need to know the low-level details of Kubernetes to under‐

stand the use cases and patterns. Architects, technical consultants, and developers

will all benefit from the repeatable patterns described here.

This book is based on use cases and lessons learned from real-world projects. We

want to help you create better cloud-native applications—not reinvent the wheel.

What You Will Learn

There’s a lot to discover in this book. Some of the patterns may read like excerpts

from a Kubernetes manual at first glance, but upon closer look you’ll see the patterns

are presented from a conceptual angle not found in other books on the topic. Other

patterns are explained with a different approach, with detailed guidelines for very

concrete problems, as in “Configuration Patterns” in Part IV.

Regardless of the pattern granularity, you will learn everything Kubernetes offers for

each particular pattern, with plenty of examples to illustrate the concepts. All these

examples have been tested, and we tell you how to get the full source code in “Using

Code Examples”.

xiv | Preface

Before we start to dive in, let’s briefly look at what this book is not:

• This book is not a guide on how to set up a Kubernetes cluster itself. Every pat‐

tern and every example assumes you have Kubernetes up and running. You have

several options for trying out the examples. If you are interested in learning how

to set up a Kubernetes cluster, we recommend Managing Kubernetes by Brendan

Burns and Craig Tracey (O’Reilly). Also, the Kubernetes Cookbook by Michael

Hausenblas and Sébastien Goasguen (O’Reilly) has recipes for setting up a

Kubernetes cluster from scratch.

• This book is not an introduction to Kubernetes, nor a reference manual. We

touch on many Kubernetes features and explain them in some detail, but we are

focusing on the concepts behind those features. Chapter 1, Introduction, offers a

brief refresher on Kubernetes basics. If you are looking for a comprehensive book

on how to use Kubernetes, we highly recommend Kubernetes in Action by Marko

Lukša (Manning Publications).

The book is written in a relaxed style, and is similar to a series of essays that can be

read independently.

Conventions

As mentioned, patterns form a kind of simple, interconnected language. To empha‐

size this web of patterns, each pattern is capitalized in italics, (e.g., Sidecar). When a

pattern is named like a Kubernetes core concept (like Init Container or Controller), we

use this specific formatting only when we directly reference the pattern itself. Where

it makes sense, we also interlink pattern chapters for ease of navigation.

We also use the following conventions:

• Everything you can type in a shell or editor is rendered in fixed font width.

• Kubernetes resource names are always rendered in uppercase (e.g., Pod). If the

resource is a combined name like ConfigMap, we keep it like this in favor of the

more natural “config map” for clarity and to make it clear that it refers to a

Kubernetes concept.

• Sometimes a Kubernetes resource name is identical to a common concept like

“service” or “node”. In these cases we use the resource name format only when

referring to the resource itself.

Preface | xv

Using Code Examples

Every pattern is backed with fully executable examples, which you can find on the

accompanying web page. You can find the link to each pattern’s example in the “More

Information” section of each chapter.

The “More Information” section also contains many links to further information

related to the pattern. We keep these lists updated in the example repository. Changes

to the link collections will also be posted on Twitter.

The source code for all examples in this book is available at GitHub. The repository

and the website also have pointers and instructions on how to get a Kubernetes clus‐

ter to try out the examples. When you go through the examples, please also have a

look into the provided resource files. They contain many useful comments that help

further in understanding the example code.

Many examples use a REST service called random-generator that returns random

numbers when called. It is uniquely crafted for playing well with the examples of this

book. Its source can be found at GitHub as well, and its container image k8spat

terns/random-generator is hosted on Docker Hub.

For describing resource fields, we use a JSON path notation. For example, .spec.rep

licas points to the replicas field of the resource’s spec section.

If you find an issue in the example code or documentation or if you have a question,

don’t hesitate to open a ticket in the GitHub issue tracker. We monitor these GitHub

issues and are happy to answer any questions over there.

All example code is distributed under the Creative Commons Attribution 4.0 (CC BY

4.0) license. The code is free to use, and you are free to share and adapt it for com‐

mercial and noncommercial projects. However, you should give attribution back to

this book if you copy or redistribute the material.

This attribution can be either a reference to the book including title, author, pub‐

lisher, and ISBN, as in “Kubernetes Patterns by Bilgin Ibryam and Roland Huß

Alternatively, add a link back to the accompanying website along with a copyright

notice and link to the license.

We love code contributions, too! If you think we can improve our examples, we are

happy to hear from you. Just open a GitHub issue or create a pull request, and let’s

start a conversation.

xvi | Preface

剩余267页未读，继续阅读

young0173

粉丝: 0
资源: 5

设计云原生应用：Kubernetes模式与ServiceMesh实践

Kubernetes Patterns

Kubernetes Patterns.pdf

Kubernetes.Patterns

FILE_PATTERNS = @Deptrum_SOURCE_DIR@/scripts/Doxyfile.in EXTRA_CONFIG_FILES += FILE_PATTERNS这样写有问题吗

design patterns 有哪些

manning.microservices.patterns

那Patterns.psp 又是什么用呢

二维码timing patterns

thinking in patterns 百度百科

最新资源