ByteCoding

架构 MariaDB ConfigMap maria-cm.yaml12345678910apiVersion: v1kind: ConfigMapmetadata: name: maria-cmdata: DATABASE: 'db' USER: 'wp' PASSWORD: '123' ROOT_PASSWORD: '123' 12$ k apply -f maria-cm.yamlconfigmap/maria-cm created Deployment maria-deploy.yaml1234567891011121314151617181920212223242526apiVersion: apps/v1kind: Deploymentmetadata: name: maria-deploy labels: app: maria-deployspec: replicas: 1 selector: matchLabels: app: maria-deploy ...

概述Service Service 本质上是一个由 kube-proxy 控制的四层负载均衡，在 TCP/IP 协议栈转发流量 四层负载均衡，在功能上非常受限，只能依据 IP 地址和端口号做一些简单的判断和组合 Service 适合代理集群内的服务，如果要将服务暴露到集群外部，需要使用 NodePort 或者 LoadBalancer Ingress 负责七层负载均衡 流量的总入口（南北向）：扇入流量 + 扇出流量 语义：集群内外边界上的入口 Ingress Controller 类比 - - - 四层 Service - iptables 规则 kube-proxy 七层 Ingress - HTTP 路由规则 Ingress Controller Service 本身没有服务能力，只是一些 iptables 规则 真正配置和应用这些 iptables 规则的是 Node 上的 kube-proxy 组件 Ingress 也只是 HTTP 路由规则的集合，相当于是一份静态描述文件 真正使得规则在集群中运行，需要 Ingress Controller，相当...

概述 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 集群 全托管 容器服务实例，无需关心底层基础设施 适合场景：只有一个容器镜像，且为无状态...