ByteCoding

网络模型 Docker bridge Docker 会创建一个名为 docker0 的虚拟网桥，默认网段为172.17.0.0/16 每个容器上都会创建一个虚拟网卡对（veth pair） 两个虚拟网卡分别连接容器和虚拟网桥，从而实现容器间的网络互通 Docker 的网络方案只局限在单机环境下工作，Kubernetes 的网络模型：IP-per-pod IP-per-pod 集群内的每个 Pod 都会有唯一的 IP 地址 Pod 内的所有容器共享这个 IP 地址 集群内的所有 Pod 都属于同一个网段 Pod 可以基于 IP 地址直接访问另一个 Pod，不需要做 NAT CNI Container Networking Interface CNI 定义了一系列通用接口，开发者只需要遵循规范接入 Kubernetes 为 Pod 创建虚拟网卡、分配 IP 地址、设置路由规则，进而实现 Kubernetes 的 IP-per-pod 网络模型 依据实现技术分类，CNI 插件可以分为 3 类 Overlay 构建一个工作在底层网络之上的逻辑网络 把原始的 Pod 网络数据包封...

Metrics Server 用来收集 Kubernetes 核心资源的指标，定时从所有 Node 的 kubelet 采集信息对集群的整体性能影响极小，性价比很高，每个 Node 大约只会占用 1m vCPU 和 2MB 内存 Metrics Server 调用 kubelet 的 API，获取到 Node 和 Pod 的指标，再将这些信息交给 API Serverkubectl 和 HPA 可以通过 API Server 来读取指标 Metrics Server 早期的数据来源是 cAdvisor，原先是一个独立的应用程序，后来被集成进 kubelet https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml --kubelet-insecure-tls 1234567891011121314151617apiVersion: apps/v1kind: Deploymentmetadata: labels: k8s-app: metrics-se...

Namespace Namespace 是一个 API 对象，但并不是一个实体对象，只是一个逻辑上的概念 123456$ k create ns test-nsnamespace/test-ns created$ k get ns test-ns -owideNAME STATUS AGEtest-ns Active 8s nginx-pod-ns.yaml12345678910apiVersion: v1kind: Podmetadata: name: nginx namespace: test-nsspec: containers: - name: nginx image: nginx:alpine 123456789101112$ k apply -f nginx-pod-ns.yamlpod/nginx created$ k get po -ntest-ns -owideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READ...

Resources 基于 cgroup 技术 内存使用 Ki、Mi、Gi 来表示 KB、MB、GB；Kubernetes 里 vCPU 的最小使用单位为 0.001，即 m nginx-pod-resources.yaml12345678910111213141516apiVersion: v1kind: Podmetadata: name: nginx-pod-resourcesspec: containers: - name: nginx image: nginx:alpine resources: requests: cpu: 10m memory: 100Mi limits: cpu: 20m memory: 200Mi 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859$ k apply -f nginx-pod-resou...

版本 使用 Pod Template Hash 作为版本号 123456789101112$ k get deployments.apps -owideNAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTORnginx-deployment 2/2 2 2 57s nginx nginx:alpine app=nginx-deployment$ k get rs -owideNAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTORnginx-deployment-756d6b7586 2 2 2 114s nginx nginx:alpine app=nginx-deployment,...

Stateful 任何应用都是有状态的 无状态应用：应用的状态信息不重要，即便不恢复也能正常运行，如 Nginx 有状态应用：应用的状态信息很重要，如 Redis、MySQL 等，其状态即在内存、磁盘上产生的数据 Kubernetes 认为状态不仅仅是数据持久化，还包括多实例的启动顺序、依赖关系和网络标识等 Stateless - Deployment：多个实例之间无关，启动顺序不固定，Pod 的名称、IP 地址也是完全随机 Stateful - StatefulSet：多个实例之间存在依赖关系 使用1234567$ k api-resources --api-group='apps'NAME SHORTNAMES APIVERSION NAMESPACED KINDcontrollerrevisions apps/v1 true ControllerRevisiondaemonsets ds apps/v1 true...

架构 搭建Server1$ sudo apt install nfs-kernel-server 配置 - /etc/exports 1/tmp/nfs 192.168.191.0/24(rw,sync,no_subtree_check,no_root_squash,insecure) 让配置生效 1234$ sudo exportfs -ra$ sudo exportfs -v/tmp/nfs 192.168.191.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,insecure,no_root_squash,no_all_squash) 启动 NFS Server 12345678910111213141516$ sudo systemctl start nfs-server$ sudo systemctl enable nfs-server$ sudo systemctl status nfs-server● nfs-server.service - NFS server and se...

概述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，相当...