架构师&容器云

1、REST是一种轻量级架构，而WebService是一种重量级架构。

2、REST既适合终端到服务的调用，系统内部子系统的互相调用，也适合不同公司之间的系统互相调用，而WebService较适合不同公司之间系统的调用

REST与WebService的区别

接口

作为一个容器，首要任务就是限制容器中进程的活动范围——能访问的文件系统目录。决不能让容器中的进程去肆意访问真实的系统目录，得将他们的活动范围划定到一个指定的区域，不得越雷池半步！

通过这两个函数，可以修改进程和系统的根目录到一个新的位置

Docker开始想办法怎么来“伪造”一个文件系统来欺骗容器中的进程

$ ls /bin dev etc home lib lib64 mnt opt proc root run sbin sys tmp usr var

用操作系统镜像文件挂载到容器进程的根目录下，变成容器的rootfs，和真实系统目录一模一样

文件系统（chroot & pivot_root）

就是如何把真实系统所在的世界隐藏起来，别让容器中的进程看到。比如进程列表、网络设备、用户列表这些，是决不能让容器中的进程知道的，得让他们看到的世界是一个干净如新的系统。

通过它可以划定一个个的命名空间，然后把进程划分到这些命名空间中。

每个命名空间都是独立存在的，命名空间里面的进程都无法看到空间之外的进程、用户、网络等等信息。

解决进程隔离问题

命名空间（namespace）

管理人员厉声说到：“帝国管理的内存快被一个叫Redis的家伙用光了，现在要挑选一些进程来杀掉，不好意思，你中奖了”

如果不对容器中的进程加以管束，那简直太危险了！除了内存，还有CPU、硬盘、网络等等资源，如果某个容器进程霸占着CPU不放手，又或者某个容器进程疯狂写硬盘，那迟早得连累到自己身上。看来必须得对这些进程进行管控，防止他们干出出格的事来。

通过它可以划定一个个的分组，然后限制每个分组能够使用的资源，比如内存的上限值、CPU的使用率、硬盘空间总量等等

系统内核会自动检查和限制这些分组中的进程资源使用量。

分组（CGroup）

docker

如果想要将 Docker 应用于庞大的业务实现，是存在困难的，编排、管理和调度问题

Docker 虽好用，但面对强大的集群，成千上万的容器，显然支撑能力就不够了

Docker痛点

K8s 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化

K8S用来管理docker容器管理软件

快速部署应用

快速扩展应用

无缝对接新的应用功能

节省资源，优化硬件资源的使用

K8S可以做到

可移植：支持公有云，私有云，混合云，多重云 multi-cloud

可扩展：模块化，插件化，可挂载，可组合

自动化：自动部署，自动重启，自动复制，自动伸缩/扩展

K8S有以下特点

云就是使用容器构建的一套服务集群网络，云由很多的大量容器构成。K8s 就是用来管理云中的容器

On-Premises（本地部署）

IaaS（基础设施即服务）

PaaS（平台即服务）

SaaS（软件即服务）

云架构分类

概念：为了让应用程序（项目，服务软件）都运行在云上的解决方案，这样的方案叫做云原生

容器化，所有服务都必须部署在容器中

微服务，Web 服务架构式服务架构

CI/CD

DevOps

特点

云原生

云和 K8s的关系

概括来说 K8s 架构就是一个 Master 对应一群 Node 节点

apiserver 即 K8s 网关，所有的指令请求都必须要经过 apiserver

scheduler 调度器，使用调度算法，把请求资源调度到某一个 Node 节点

controller 控制器，维护 K8s 资源对象

etcd 存储资源对象

Master 节点结构

kubelet 在每一个 Node 节点都存在一份，在 Node 节点上的资源操作指令由 kubelet 来执行

kube-proxy 代理服务，处理服务与服务间负载均衡

Pod 是 k8s 管理的基本单元（最小单元），Pod 内部是容器，k8s 不直接管理容器，而是管理 Pod

Docker 运行容器的基础环境，容器引擎

Fluentd 日志收集服务

Node节点结构

K8s 是用来管理容器，但是不直接操作容器，最小操作单元是 Pod （间接管理容器）

一个 Master 有一群 Node 节点与之对应

Master 节点不存储容器，只负责调度、网管、控制器、资源对象存储

容器的存储在 Node 节点，容器是存储在 Pod 内部的

Pod 也是一个容器，这个容器中装的是 Docker 创建的容器，Pod 用来封装容器的一个容器，Pod 是一个虚拟化分组

Pod 相当于独立主机，可以封装一个或者多个容器

Pod 有自己的 IP 地址、主机名，相当于一台独立沙箱环境

通常情况下，在服务部署时候，使用 Pod 来管理一组相关的服务。一个 Pod 中要么部署一个服务，要么部署一组有关系的服务

Pod 内部可以有一个容器，或者多个容器

Kubelet 负责本地 Pod 的维护

Kube-proxy 负责负载均衡，在多个 Pod 之间来做负载均衡

K8S核心组件

Pod 中的容器很可能因为各种原因发生故障而死掉。Deployment 等 Controller 会通过动态创建和销毁 Pod 来保证应用整体的健壮性。换句话说，Pod 是脆弱的，但应用是健壮的。每个 Pod 都有自己的 IP 地址。当 controller 用新 Pod 替代发生故障的 Pod 时，新 Pod 会分配到新的 IP 地址 ；如果一组 Pod 对外提供服务（比如 HTTP），它们的 IP 很有可能发生变化，那么客户端如何找到并访问这个服务呢？

K8s 给出的解决方案是 Service。 Kubernetes Service 从逻辑上代表了一组 Pod，具体是哪些 Pod 则是由 Label 来挑选。                                                  Service 有自己 IP，而且这个 IP 是不变的。客户端只需要访问 Service 的 IP，K8s 则负责建立和维护 Service 与 Pod 的映射关系。无论后端 Pod 如何变化，对客户端不会有任何影响，因为 Service 没有变。

Service 资源对象包括如下三部分：Pod IP：Pod 的 IP 地址Node IP：物理机 IP 地址Cluster IP：虚拟 IP ，是由 K8s 抽象出的 Service 对象，这个 Service 对象就是一个 VIP 的资源对象Service VIP 更深入原理探讨

Service 如何实现负载均衡

K8s负载均衡实现

K8s架构原理

自动化运维平台，创业型公司，中小型企业，使用 K8s 构建一套自动化运维平台，自动维护服务数量，保持服务永远和预期的数据保持一致性，让服务可以永远提供服务。这样最直接的好处就是降本增效

K8S应用场景

K8S

浏览器控制台执行代码_chrome浏览器中 F12 功能的简单介绍

F12调试

架构师