单体架构：可以理解为主要业务逻辑模块（我们编写的代码模块，不包括独立的中间件）运行在一个进程中的应用，最典型的是运行在一个Tomcat容器中，位于一个进程里。单体架构好处是技术门槛低、编程工作量少、开发简单快捷、调试方便、环境容易搭建、容易发布部署及升级，开发运维等总体成本很低、见效快。其缺点也明显：
（1）单体应用系统比较膨胀与臃肿，耦合度高，导致进行可持续开发和运维很困难。
（2）单体应用难以承载迅速增长的用户请求和需求。
基于Spring Framework的单体应用架构图
分布式架构核心思想是把一个单一进程的系统拆分为功能上相互协作又能独立部署在多个服务器上的一组进程，这样一来，系统可以根据实际业务需要，通过以下两种方式实现某些独立组件的扩容，提升吞吐量。
水平扩展：通过增加服务器数量进行扩容
垂直扩展：给系统中的某些特殊业务分配更好的机器，提供更多资源，从而提升这些业务的系统负载和吞吐
分布式架构是将一个庞大的单体应用拆分成多个独立运行的进程，这些进程能通过某种方式实现远程调用，因此，分布式架构要解决的第一个核心技术问题就是独立进程之间的远程通信。该问题的最早答案就是RPC技术（Remote Procedure Call），一种典型的微服务架构平台的结构示意图如下：
大家比较熟知的微服务架构框架有Dubbo与Spring Cloud，之后比较成功的微服务架构基本都和容器技术挂钩了，其中最成功的、影响最大的当属Kubernetes平台了，与之相似的还有Docker公司推出的Docker Swarm(在2017年底，Docker Swarm也支持Kubernetes了)。
关于微服务架构的优势由于文章篇幅有限，不再展开，但任何技术都存在两面性，微服务架构具有一定的复杂性，如开发者必须掌握某种RPC技术，并且必须通过写代码来处理RPC速度过慢或者调用失败等复杂问题。为了解决微服务带来的编程复杂性问题，一种新的架构设计思想出现了，这就是Service Mesh，Service Mesh定义是：一个用于处理服务于服务之间通信（调用）的复杂的基础架构设施。从本质上看，Service Mesh是一组网络代理程序组成的服务网络，这些代理会与用户程序部署在一起，充当服务代理，这种代理后来在Google的Istio产品架构中称为“Sidecar”，其实就是采用了代理模式的思想去解决代码入侵及重复编码的问题，。下图给出了Service Mesh最简单的架构图。Servie Mesh同样不是本次的主角，感兴趣的小伙伴可自行学习。
官方原文是：K8s is an abbreviation derived by replacing the 8 letters “ubernete” with 8.
k8s全称kubernetes，名字来源于希腊语，意思为“舵手”或“领航员”，它是第一代容器技术的微服务架构（第二代是Servie Mesh）。
Kubernetes最初源于谷歌内部的Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的workflows 和更高级的自动化任务。
Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。
Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
Kubernetes主要由以下几个核心组件组成：
API对象是k8s集群中的管理操作单元。k8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理操作。例如副本集Replica Set对应的API对象是RS。
k8s采用声明式操作，由用户定义yaml，k8s的API负责创建。每个对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望k8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
apiVersion - 创建对象的Kubernetes API 版本
kind - 要创建什么样的对象？
metadata- 具有唯一标示对象的数据，包括 name（字符串）、UID和Namespace（可选项）
使用上述.yaml文件创建Deployment，是通过在kubectl中使用kubectl create命令来实现。将该.yaml文件作为参数传递。如下例子：
$ kubectl create -f docs/user-guide/nginx-deployment.yaml --record
k8s常见对象：Pod、复制控制器（Replication Controller,RC）、副本集（Replica Set,RS）、部署（Deployment）、服务（Service）、任务（Job）、存储卷（Volume）、持久存储卷和持久存储卷声明（Persistent Volume,PV、Persistent Volume Claim,PVC）、节点（Node）、ConfigMap、Endpoint等。
每个模块都可以在必要时优雅地降级服务控制逻辑应该只依赖于当前状态。这是为了保证分布式系统的稳定可靠，对于经常出现局部错误的分布式系统，如果控制逻辑只依赖当前状态，那么就非常容易将一个暂时出现故障的系统恢复到正常状态，因为你只要将该系统重置到某个稳定状态，就可以自信的知道系统的所有控制逻辑会开始按照正常方式运行。
假设任何错误的可能，并做容错处理。在一个分布式系统中出现局部和临时错误是大概率事件。错误可能来自于物理系统故障，外部系统故障也可能来自于系统自身的代码错误，依靠自己实现的代码不会出错来保证系统稳定其实也是难以实现的，因此要设计对任何可能错误的容错处理。
尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。因为分布式系统各个子系统都是不能严格通过程序内部保持同步的，所以如果两个子系统的控制逻辑如果互相有影响，那么子系统就一定要能互相访问到影响控制逻辑的状态，否则，就等同于系统里存在不确定的控制逻辑。
假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。由于分布式系统的复杂性以及各子系统的相对独立性，不同子系统经常来自不同的开发团队，所以不能奢望任何操作被另一个子系统以正确的方式处理，要保证出现错误的时候，操作级别的错误不会影响到系统稳定性。
每个模块都可以在出错后自动恢复。由于分布式系统中无法保证系统各个模块是始终连接的，因此每个模块要有自我修复的能力，保证不会因为连接不到其他模块而自我崩溃。
每个模块都可以在必要时优雅地降级服务。所谓优雅地降级服务，是对系统鲁棒性的要求，即要求在设计实现模块时划分清楚基本功能和高级功能，保证基本功能不会依赖高级功能，这样同时就保证了不会因为高级功能出现故障而导致整个模块崩溃。根据这种理念实现的系统，也更容易快速地增加新的高级功能，以为不必担心引入高级功能影响原有的基本功能。
容器云平台如何对租户可用资源进行精细管理，对平台的可用性、可维护性和易用性起着至关重要的作用，是容器云平台能够为用户提供丰富的微服务管理的基石。在云计算领域，资源可被分为计算资源、网络资源和存储资源三大类，也可被分别称作计算云、网络云和存储云。
在k8s集群中，提供计算资源的实体叫做Node，Node既可以是物理机服务器，也可以是虚拟机服务器，每个Node提供了CPU、内存、磁盘、网络等资源。每个Node（节点）具有运行pod的一些必要服务，并由Master组件进行管理，Node节点上的服务包括Docker、kubelet和kube-proxy。
通过引入Namespace，k8s将集群近一步划分为多个虚拟分组进行管理，Namespace所实现“分区”是逻辑上的，并不与实际资源绑定，它用于多租户场景实现资源分区和资源最大化利用。
大多数Kubernetes资源（例如pod、services、replication controllers或其他）都在某些Namespace中，但Namespace资源本身并不在Namespace中。而低级别资源（如Node和persistentVolumes）不在任何Namespace中。Events是一个例外：它们可能有也可能没有Namespace，具体取决于Events的对象。
Pod是Kubernetes创建或部署的最小/最简单的基本单位，一个Pod代表集群上正在运行的一个进程。
一个Pod封装一个应用容器（也可以有多个容器），存储资源、一个独立的网络IP以及管理控制容器运行方式的策略选项。Pod代表部署的一个单位：Kubernetes中单个应用的实例，它可能由单个容器或多个容器共享组成的资源。
每个Pod都是运行应用的单个实例，如果需要水平扩展应用（例如，运行多个实例），则应该使用多个Pods，每个实例一个Pod。在Kubernetes中，这样通常称为Replication。Replication的Pod通常由Controller创建和管理。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和集群级别的自愈能力。例如，如果一个Node故障，Controller就能自动将该节点上的Pod调度到其他健康的Node上。
docker本身比较重，2015年OCI（Open ContainerInitiative）诞生，它定义了镜像标准、运行时标准和分发标准，由于k8s 本身不具备创建容器的能力，是通过 kubelet 组件调用容器运行时 API 接口和命令来创建容器，Kubernete 与 容器运行时的关系是历史性的，也很复杂。但是随着 Kubernete 弃用 Docker ，目前主流的运行时主要是 containerd 和 CRI-O
“one-container-per-Pod”模式是Kubernetes最常见的用法，一个Pod也可以有多个容器。
在k8s中，可以从Namespace、Pod和Container三个级别区管理资源的配置和限制。例如：
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-3
spec:
containers:
- name: memory-demo-3-ctr
image: vish/stress
resources:
limits:
memory: "1000Gi"
requests:
memory: "1000Gi"
args:
- -mem-total
- 150Mi
- -mem-alloc-size
- 10Mi
- -mem-alloc-sleep
- 1s
apiVersion: v1
kind: LimitRange
metadata:
name: mylimits
spec:
limits:
- max:
cpu: "4"
memory: 2Gi
min:
cpu: 200m
memory: 6Mi
maxLimitRequestRatio:
cpu: 3
memory: 2
type: Pod
- default:
cpu: 300m
memory: 200Mi
defaultRequest:
cpu: 200m
memory: 100Mi
max:
cpu: "2"
memory: 1Gi
min:
cpu: 100m
memory: 3Mi
maxLimitRequestRatio:
cpu: 5
memory: 4
type: Container
apiVersion: v1
kind: ResourceQuota
metadata:
name: pod-demo
spec:
hard:
request.cpu: "4"
request.memory: 8GB
limit.memory:16GB
pods: "2"
node Ip：node节点的ip，为物理ip.
pod Ip：pod的ip，即docker 容器的ip，为虚拟ip。
cluster Ip：service 的ip，为虚拟ip。提供一个集群内部的虚拟IP以供Pod访问。实现原理是通过Linux防火墙规则，属于NAT技术。当访问ClusterIP时，请求将被转发到后端的实例上，如果后端实例有多个，就顺便实现了负载均衡，默认是轮训方式。
在k8s体系中，k8s的网络模型设计的一个基本原则：每个pos都拥有一个独立的IP地址，而且假定所有的Pod都在一个可以直接联通的、扁平的网络空间中，不管它们是否运行在同一个Node（宿主机）中，都可以直接通过对方的IP进行访问。但k8s本身并不提供跨主机的容器网络解决方案。公有云环境（例如AWS、Azure、GCE）通常都提供了容器网络方案，但是在私有云环境下，仍然需要容器云平台位不同的租户提供各种容器网络方案。
目前，为容器设置Overlay网络是最主流的跨主机容器网络方案。Overlay网络是指在不改变原有网络配置的前提下，通过某种额外的网络协议，将原IP报文封装起来形成一个逻辑上的网络。在k8s平台上，建议通过CNI插件的方式部署容器网络。
CNI（Container Network Interface）是CNCF基金会下的一个项目，由一组用于配置容器的网络接口的规范和库组成，它定义的是容器运行环境与网络插件之间的接口规范，仅关心容器创建时的网络配置和容器被销毁是网络资源的释放，并且一个容器可以绑定多个CNI网络插件加入网络中，如下图。
目前比较流程的CNI插件实现方式有Flannel、Calico、macvlan、Open vSwitch、直接路由。
在k8s集群内，应用默认以Service的形式提供服务，有kube-proxy实现Service到容器的负载均衡器的功能，如下图定义一个mysql service：
kind: Service
apiVersion: v1
metadata:
name: mysql-master
spec:
selector:
app: mysql-master
ports:
port: 3306
targetPort: 3306
此时，集群外是无法访问这个Service的。对于需要k8s集群外的客户端提供服务的Service，可以通过Ingress将服务暴露出去，并且如果该集群（网络）拥有真实域名，则还能将Service直接与域名进行对接。
k8s将一个Ingress资源对象的定义和一个具体的Ingress Controller相结合来实现7层负载均衡器。Ingress Controller在转发客户请求到后端服务时，将跳过kube-proxy提供的4层负载均衡器的功能，直接转发到Service的后端Pod（Endpoints），以提高网络转发效率。
如上图展示了一个典型的HTTP层路由的Ingress例子，其中：
对http://mywebsite.com/api的访问将被路由到后端名为“api”的Service；
对http://mywebsite.com/web的访问将被路由到后端名为“web”的Service；
对http://mywebsite.com/doc的访问将被路由到后端名为“doc”的Service。
如下是一个典型的Ingress策略定义，Ingress Controller将对目标地址http://mywebsite.com/demo的访问请求转发到集群内部服务的webapp(webapp:8080/demo)
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: mywebsite-ingress
spec:
rules:
-host：mywebsite.com
http:
paths:
- path: /demo
backend:
serviceName: webapp
servicePort: 8080
常用的Ingress Controller有：Nginx、HAProxy、Traefik、apisix等。
使用emptyDir，当Pod分配到Node上时，将会创建emptyDir，并且只要Node上的Pod一直运行，Volume就会一直存。当Pod（不管任何原因）从Node上被删除时，emptyDir也同时会删除，存储的数据也将永久删除。注：删除容器不影响emptyDir。
ConfigMap：将保存在ConfigMap资源对象中的配置文件信息挂载到容器的某个目录下
Secret：将保存在Secret资源对象中的密码密钥等信息挂载到容器内的某个文件中
DownwardApI：将downward API的数据以环境变量或文件的形式注入容器中
gitRepo：将某Git代码库挂载到容器内的某个目录下
hostPath：将宿主机的目录或文件挂载到容器内进行使用
local：从v1.9版本引入，将本地存储以PV形式提供给容器使用，并能够给实现存储空间的管理
PV（Persistne Volume）：将共享存储定义为一种“持久存储卷”，可以被多个容器共享使用
PVC（Persistne Volume Claim）：用户对存储资源的一次“申请”，PVC申请的对象是PV，一旦申请成功，应用就能够想使用本地目录一样使用共享存储卷。下图是一个PV对象ymal定义：
apiVersion: v1
kind: PersistentVolume
metadata:
name: example-pv
annotations:
"volume.alpha.kubernetes.io/node-affinity": '{
"requiredDuringSchedulingIgnoredDuringExecution": {
"nodeSelectorTerms": [
{ "matchExpressions": [
{ "key": "kubernetes.io/hostname",
"operator": "In",
"values": ["example-node"]
}
]}
]}
}'
spec:
capacity:
storage: 100Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Delete
storageClassName: local-storage
local:
path: /mnt/disks/ssd1
PV和PVC相互关系生命周期如上图所示，k8s的共享存储供应模式包括静态模式（Static）和动态模式（Dynamic），资源供应的结果就是创建好的PV。运维人员手动创建PV就是静态，而动态模式的关键就是StorageClass，它的作用就是创建PV模板。
创建StorageClass里面需要定义PV属性比如存储类型、大小等；另外创建这种PV需要用到存储插件。最终效果是，用户提交PVC，里面指定存储类型，如果符合我们定义的StorageClass，则会为其自动创建PV并进行绑定。
下图通过ymal创建一个StorageClass对象
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: standard
provisioner: kubernetes.io/aws-ebs // 存储分配器
parameters:
type: gp2
reclaimPolicy: Retain // 回收策略
mountOptions:
- debug
StorageClass和PV、PVC之间的运作关系如下图所示：
CSI（Container Storage Interface）与k8s的关系与CNI有点类似，CSI旨在容器和共享存储之间建议一套标准的存储访问接口。在它诞生前，经历了“in-tree”方式、FlexVolume模式。
CSI规范用语将存储供应商代码与k8s代码完全解耦，存储插件的代码由存储供应商自行维护。
和kube-apiserver直接进行交互的是K8S官方直接提供的一些sidecar容器，这些sidecar直接部署即可。这些sidecar容器（主要是上图的三个主要部件）监听自己对应的CRD，触发对应的操作，通过UDS接口直接调用CSI driver的接口（例如CreateVolume() 、NodePublishVolme()等）来实现对卷的操作。
要开发CSI Drivers一般来说实现以下几个服务：
允许调用者(Kubernetes组件和CSI sidecar容器)识别驱动程序及其支持的可选功能。
NodePublishVolume, NodeUnpublishVolume 和 NodeGetCapabilities 是必须的。
所需的方法使调用者能够使卷在指定的路径上可用，并发现驱动程序支持哪些可选功能。
实现CreateVolume、DeleteVolume接口
Federation是Kubernetes的子项目，其设计目标是对多个Kubernetess集群进行统一管理，将用户的应用部署到不同地域的数据中心。Federation引入了一个位于Kubernetes集群只上的控制平面，屏蔽了后端各k8s子集群，向客户提供了统一的管理入口，如下图:
Federation控制平面“封装”了多个k8s集群的Master角色，提供了统一的Master，包括Federation API Server、Federation Controller Manafer，用户可以向操作单个集群一样操作Federation，还统一了全部k8s集群的DNS、ConfigMap，并将数据保存在集中的etcd数据库中。
对于k8s初学者来说，对k8s的第一印象应该是概念多，名词多。《kubernetes权威指南：企业级容器云实战》这本书从企业实践角度入手，讲述了技术的演进，并在很多场景提供了不同技术实现的对比，结合k8s中文社区，这本书可以作为学习k8s的入门书籍。本文实际上是此书的一篇读书笔记，文章从计算资源、网络资源、存储资源三个方向展开，介绍了k8s里一些常见的概念和对象。由于篇幅问题，很多也很重要的概念并没有在文中详细介绍，读者可根据自身情况展开补充学习。关于k8s核心组件及工作原理将在后续陆续推出。
在某些虚拟化，免安装，打点，环境检测，拦截器等场景，针对`Android`系统服务接口的拦截是常用的技术方案。通常只是针对正向的接口调用，如果涉及被动的服务回调拦截，则实现起来就有些许麻烦。