ByteCoding

概述 Service 是集群内部的负载均衡机制，用于解决服务发现的关键问题 工作原理 Kubernetes 为 Service 分配一个静态 IP，由 Service 自动管理和维护动态变化的 Pod 集合 当客户端访问 Service 时，Service 会根据某种策略，将流量转发到某个 Pod Service 使用了 iptables 每个 Node 上的 kube-proxy 自动维护 iptables 规则 负载均衡：Service 会根据 iptables 规则转发请求给它管理的多个 Pod Service 也可以使用其它技术实现负载均衡 性能更差的 userspace 性能更好的 ipvs YAML Service 为 Kubernetes 的核心对象，不关联业务应用 12345678910111213141516171819$ k api-resources --api-group=""NAME SHORTNAMES APIVERSION NAMESPACED KINDbindings ...

YAML 与 Deployment 非常类似，但缺少 replicas，因为 Daemonset 的意图是在每个 Node 上部署一个 Pod redis-ds.yml123456789101112131415161718192021apiVersion: apps/v1kind: DaemonSetmetadata: name: redis-ds labels: app: redis-dsspec: selector: matchLabels: name: redis-ds template: metadata: labels: name: redis-ds spec: containers: - name: redis image: redis:5-alpine ports: - containerPort: 6379 使用12345678910$ k apply -f redis-ds.ymldaemonset.apps/redis-ds created$ k ...

API1234567$ k api-resources --api-group=appsNAME SHORTNAMES APIVERSION NAMESPACED KINDcontrollerrevisions apps/v1 true ControllerRevisiondaemonsets ds apps/v1 true DaemonSetdeployments deploy apps/v1 true Deploymentreplicasets rs apps/v1 true ReplicaSetstatefulsets sts apps/v1 true StatefulSet YAML12345678910111213141516171819...

架构 准备 修改主机名，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,...

架构 常见 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: - containe...

定义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.ym...

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 系统的优劣 简化了对象存储的逻辑和设计，云厂商可以更聚焦于对象存储的分布式架构和服务高可用上 但对象存储中的"目录"操作的代价变高了 目录删除/重命名...