ByteCoding

概述PersistentVolume Pod 里的容器由镜像产生，镜像文件本身是只读的，进程要读写磁盘需要一个临时的存储空间 一旦 Pod 销毁，临时存储会被立即释放，数据也就丢失了 PersistentVolume 用来表示持久存储设备，隐藏了存储的底层实现 PersistentVolume 实际是一些存储设备和文件系统，如 Ceph、GlusterFS、NFS、本地磁盘 PersistentVolume 是属于集群的系统资源，是和 Node 平级的对象，Pod 只有使用权 PersistentVolumeClaim + StorageClass PersistentVolumeClaim 和 StorageClass 是 Pod 与 PersistentVolume 之间的中间层 Pod 用 PersistentVolumeClaim 来向 Kubernetes 申请存储资源 bind：一旦资源申请成功，Kubernetes 会把 PV 和 PVC 关联在一起 StorageClass 类似于 IngressClass，抽象了特定类型的存储系统 在 PVC 和 PV 之间充当协调人...

架构 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：关注数据流，是数据的传递和流向...