ByteCoding

架构 准备 修改主机名，Kubernetes 使用主机名来区分集群中的节点，不能重名 hostname ip master mac-master 192.168.191.144 worker mac-worker 192.168.191.146 123456789101112131415161718192021$ ip a1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever2: ens160: <BROADCAST,MUL ...

架构 常见 API 对象 ConfigMap 和 Secret 只接受字符串类型 部署 MariaDBmaria-cm.yml12345678910apiVersion: v1kind: ConfigMapmetadata: name: maria-cmdata: DATABASE: 'db' USER: 'wp' PASSWORD: '123' ROOT_PASSWORD: '123' envFrom - 更简洁 maria-pod.yml12345678910111213141516171819apiVersion: v1kind: Podmetadata: name: maria-pod labels: app: wordpress role: databasespec: containers: - name: maria image: mariadb:10 imagePullPolicy: IfNotPresent ports: - containerPo ...

定义ConfigMap 明文配置 12345678$ k create cm info --from-literal=name=zhongmingmao --dry-run=client -oyamlapiVersion: v1data: name: zhongmingmaokind: ConfigMapmetadata: creationTimestamp: null name: info ConfigMap 没有 spec，因为 ConfigMap 存储的是配置数据，并不是容器，因此没有运行时规格 ConfigMap 里的数据都是 Key-Value 结构 cm.yml12345678910apiVersion: v1kind: ConfigMapmetadata: name: infodata: name: zhongmingmao city: guangzhou greeting: | hello kubernetes! 123456789101112131415161718192021222324252627282930$ k apply -f cm.ymlco ...

Serverless vs Container Serverless 是云计算中资源抽象的极致体现：用户专注于业务逻辑，而无需关注基础设施 Container 给予了用户很大的定制空间，按需对应用进行拆分和封装 Serverless 完全屏蔽了计算资源，引导用户不再关注基础设施，只需遵循标准的方式编写业务代码即可 更细的拆分粒度 FaaS：将每一个具有独立功能的函数，作为一个单独的服务进行部署和运行 计费机制 底层没有固化的资源，一般会按照调用次数和调用时长来计费，可以精确到毫秒 从成本上，非常适合那些偶尔触发、短时间运行的工作负载 事件模型 事件模型是 Serverless 的核心编程模型和运行逻辑，非常适合基于事件驱动的开发场景 上游：触发器 Serverless 一般都会提供多种触发器：API 触发器、OSS 触发器、MQ 触发器、定时触发器等 下游 在函数内访问其他云服务（如 RDS、MQ 等外部存储） Serverless Computing 本身是无状态的，所有持久化需求都需要借助外部存储来实现 架构范式 FaaS + MQ：关注数据流，是数据的传递和流向 当 ...

历史 相辅相成：云承载着容器的运行，容器生态驱动着云的发展 初期的首要目标：Docker 容器在云上能够顺畅运行 帮助用户创建底层虚拟机集群，免去用户自己手动管理虚拟机的麻烦 随着容器应用的复杂化，容器编排成为了用户最迫切的需求 Kubernetes 赢得了编排框架大战，成为了事实标准 自建 vs 托管 由于云端的多租户特性，云平台会统一提供和托管 Master 节点，降低运维成本 只需要创建 Worker 节点，并为之付费即可 Kubernetes 的抽象设计非常出色，能够支持大量灵活的扩展 云厂商会让尽量多的 IaaS 和 PaaS 功能组件，渗透到 Kubernetes 的体系中 Cloud Service Operator 通过云服务来扩展 Kubernetes 的能力，并反过来使用 Kubernetes 来管理这些云服务 成熟：容器和云一体化架构 多集群 降低了建立 Kubernetes 集群的门槛，如果业务关联较小，可以为不同的业务创建单独的 Kubernetes 集群 全托管 容器服务实例，无需关心底层基础设施 适合场景：只有一个容器镜像，且为无状态，只想 ...

RDS Relational Database Service 一般针对每个数据库引擎，都会有对应的服务：RDS for MySQL、RDS for PostgreSQL 同一个数据库按照不同的版本，会有比较严格的分支选项，在创建时指定 RDS vs 传统关系型数据库 编程接口 + 使用体验：几乎完全一致 云厂商会把功能、内部机制完整地保留下来，获得最大程度的兼容性 运维（开箱即用）：智能化 + 自动化 读写分离 自动调优：自动发现性能热点，智能给出调整建议 云原生数据库 完全为云设计、充分发挥云的特点和优势 出于生态发展和降低学习难度的需要，绝大多数的云原生数据库仍然保留了 SQL 接口 不同领域的云原生数据库：关系型、键值型、文档型、图数据库、分析型 优势 更强的可扩展性 计算：可以利用云快速进行水平扩展 存储：基于原生设计的计算存储分离架构，可以支撑更大规模的数据量 更高的可用性和可靠性 原生机制：默认多副本高可用 基于原生数据同步机制的底层设计，可以方便地支持跨区域的实例复制（增强冗余 + 就近服务用户） 支持多种数据模型 兼容关系型数据库后，针对不同场景，推出不 ...

概述 对象：任意二进制文件，包括结构化和非结构化的数据，可随时执行：上传、下载、修改、删除 对象存储 vs 云硬盘 访问接口和形式 云硬盘是挂载到虚拟机的虚拟硬盘，是通过实现 OS 的底层接口，作为虚拟机的块存储设备而存在 必须连接到相关的虚拟机，才能访问到云硬盘里面的数据 对象存储，本质上是一个网络化的服务，调用方主要通过高层的 API 或者 SDK 来和它进行交互 提供类似 HTTP 的网络接口来实现，独立性很强 S3FS 和 OSSFS 等工具可以通过模拟磁盘（基于对象存储的 API ）并挂载到虚拟机 并没有改变对象存储是网络化服务的本质 云硬盘位于 IaaS 层，而对象存储位于 PaaS 层 KV 系统 vs 文件系统 Key 为存储对象的路径，Value 为存储对象的二进制文件 文件系统保存了更多的元数据（如：实现目录结构和目录操作），KV 系统的目录是通过共享前缀路径来模拟的 KV 系统的优劣 简化了对象存储的逻辑和设计，云厂商可以更聚焦于对象存储的分布式架构和服务高可用上 但对象存储中的"目录"操作的代价变高了 目录删除/重命名：需要 ...

概述 PaaS 在 IaaS 的基础上，构建了很多关键抽象和可复用的单元，让用户更聚焦业务 优势 PaaS 更符合云的初衷，代表了一种完全托管的理想主义，代表对研发生产力的极致追求 核心优势：生产力（搭建 + 运维） 维度 PaaS 服务是否带有内生的运行环境（Web 服务带有编程语言运行时、数据库服务带有 SQL 执行引擎） PaaS 存在的位置和范围，以及开放给用户的控制粒度 – Region / Availability zone / VPC PaaS 服务是否有状态（数据属性） PaaS 服务的虚拟机是否对外暴露 暴露虚拟机的 PaaS 服务，拥有更高的开放程度，与 IaaS 的结合也更加紧密，成本更低 不暴露虚拟机的 PaaS 服务，拥有更好的独立性和封装性 – 数据库服务 权衡 PaaS 的核心理念在于封装：封装提升了效率，但牺牲了灵活性

历史 基于 Linux 的 Namespace 、Cgroup和 Union FS，对进程进行封装隔离，属于 OS 层的虚拟化技术 Docker 最初的实现是基于 LXC 从 0.7 以后开始移除 LXC，而使用自研的 Libcontainer 从 1.11 开始，使用 runC 和 Containerd Docker 在容器的基础上，进行进一步的封装，极大地简化容器的创建和维护 Docker vs VM 特性 Docker VM 启动 秒级 分钟级 磁盘 MB GB 性能 接近原生 弱于 数量 单机上千个容器 几十个 容器标准 OCI - Open Container Initiative Key Value Image Specification 如何打包 Runtime Specification 如何解压应用包并运行 Distribution Specification 如何分发镜像 主要特性 隔离性（Namespace）、可配额（CGroup）、便携性（Union FS）、安全性 Namespace Linux Namespace 是 ...

Design for Failure 核心思路：冗余 + 快速切换 宿主机 保证多个虚拟机不在同一个宿主机上，甚至不处于同一个机架上 提供物理分散分布的能力：AWS（Placement Group）、Azure（Availability Set）、阿里云（部署集） 可用区 - IDC 多可用区的实例部署（VPC 支持跨可用区） 区域 多区架构层面的相关预案 互联网业务：通过 DNS 导流，将域名解析到另一个区域的备用服务，底层数据依赖日常的跨区域的实时同步 多云 - 避免厂商锁定 Auto scaling 应对工作负载洪峰 + 在低谷期显著降低成本 虚拟机编组 将功能相同的多个虚拟机，作为一个单位来创建、管理和伸缩 弹性伸缩服务 根据指定的数量和扩缩容的规则，动态地创建和销毁虚拟机实例，协调虚拟机的生命周期 负载均衡器 - SLB 将流量均匀地、或者按照一定权重或规则，分发到多台虚拟机上 弹性伸缩服务 + 负载均衡器：适合处理无状态类的计算需求