容器编排 -- Deployment
基本概念 Deployment实现了Pod的水平伸缩（horizontal scaling out/in） – 滚动更新（rolling update） 滚动更新依赖于ReplicaSet Deployment控制ReplicaSet（版本），ReplicaSet控制Pod（副本数）！！ ReplicaSet ReplicaSet的定义是Deployment的一个子集 Deployment控制器实际操纵对象是ReplicaSet，而非Pod，Deployment所管理的Pod的ownerReference为ReplicaSet 12345678910111213141516171819apiVersion: apps/v1kind: ReplicaSetmetadata: name: nginx-set labels: app: nginxspec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx sp...
容器编排 -- 控制器模型
控制器 kube-controller-manager是一系列控制器的集合，每一种控制器都以独有的方式负责某种编排功能 1234567# cd kubernetes/pkg/controller# ls -d */apis/ cronjob/ endpoint/ history/ nodelifecycle/ replication/ storageversiongc/ util/bootstrap/ daemon/ endpointslice/ job/ podautoscaler/ resourcequota/ testutil/ volume/certificates/ deployment/ endpo...
容器编排 -- Pod
基本概念 在Kubernetes中，Pod是一等公民 Pod是Kubernetes的原子调度单位，Kubernetes统一按照Pod（而非容器）的资源需求进行计算 容器的本质是进程 容器的单进程模型 并不是指容器里只能运行一个进程，而是指容器没有管理多个进程的能力 原因 容器里PID=1的进程是应用本身，其它进程都是PID=1进程的子进程 用户编写的应用，并不能像正常OS里面的init进程或者systemd进程那样拥有进程管理的功能 容器间具有『超亲密关系』的典型特征 互相之间会发生直接的文件交换 使用localhost或者Socket文件进行本地通信 会发生非常频繁的远程调用 需要共享某些Linux Namespace 并不是所有有关系的容器都属于同一个Pod，如Java应用容器和MySQL更适合做成两个Pod Pod在Kubernetes中的重要意义 – 容器设计模式 实现原理 Pod只是一个逻辑概念 Kubernetes真正处理的，还是宿主机上Linux容器的Namespace和Cgroups，并不存在所谓的Pod的边界或者隔离环境 Pod里的所有容器，共...
Kubernetes -- 集群搭建 & 应用容器化
kubeadm安装1$ apt-get install kubeadm 步骤12345# 创建一个Master节点$ kubeadm init# 将一个Worker节点加入到当前集群中$ kubeadm join <Master节点的IP和端口> 工作原理 直接容器化kubelet会面临很多问题，所以把kubelet直接运行在宿主机上，然后使用容器部署其它的Kubernetes组件 工作流程kubeadm initPreflight Checks 进行一系列的检查工作，确保该机器可以用来部署Kubernetes Linux内核版本 ≥ 3.10 Linux Cgroups模块可用 机器的hostname标准（符合标准的DNS命名） kubeadm与kubelet的版本匹配 机器上已经安装了Kubernetes的二进制文件 Kubernetes的工作端口（10250/10251/10252）没有被占用 ip、mount等Linux指令存在 Docker已经安装 生成证书 生成Kubernetes对外提供服务所需的各种证书和对应的目录 Kubernetes对外...
Kubernetes -- 架构 & 设计思想
容器 本质：由Linux Namespace、Linux Cgroups和rootfs三种技术构建出来的进程的隔离环境 容器的视图 静态视图（Container Image）：一组联合挂载在/var/lib/docker/aufs/mnt上的rootfs 动态视图（Container Runtime）：由Namespace+Cgroups构成的隔离环境 开发人员并不关心Container Runtime的差异，因为承载容器信息进行传递的，是Container Image Kubernetes架构 角色：Master（控制节点）、Node（计算节点） Master kube-apiserver：负责API服务，整个集群的持久化数据，由kube-apiserver处理后保存在Etcd中 kube-scheduler：负责调度 kube-controller-manager：负责容器编排 Node：kubelet，为最核心的组件 CRI，Container Runtime Interface 主要负责与Container Runtime打交道 只要Container Runtime能够运行标准...
容器基础 -- Docker容器
文件12# lsapp.py Dockerfile requirements.txt app.py1234567891011121314from flask import Flaskimport socketimport osapp = Flask(__name__)@app.route('/')def hello(): html = "<h3>Hello {name}!</h3>" \ "<b>Hostname:</b> {hostname}<br/>" return html.format(name=os.getenv("NAME", "world"), hostname=socket.gethostname())if __name__ == "__main__": app.run(host='0.0.0.0', por...
容器基础 -- rootfs
环境12345678# cat /etc/issueUbuntu 16.04.7 LTS \n \l# uname -aLinux ubuntu1604 4.4.0-186-generic #216-Ubuntu SMP Wed Jul 1 05:34:05 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux# docker --versionDocker version 18.03.1-ce, build 9ee9f40 12345678910# grep aufs /proc/filesystemsnodev aufs# cat /etc/docker/daemon.json{ "storage-driver": "aufs"}# docker info | grep 'Storage Driver'Storage Driver: aufs Mount Namespace创建子进程时开启Namespace 123456789101112131415161718192021222...
容器基础 -- Namespace & Cgroups
VM vs Container Hypervisor 通过硬件虚拟化，模拟出一个操作系统所需要的各种硬件，然后在虚拟的硬件上安装Guest OS 对应用进程的隔离环境负责 额外的资源消耗和占用 使用虚拟化技术作为应用沙盒，必须由Hypervisor来负责创建VM，该VM是真实存在的且里面运行一个完整的Guest OS Docker Engine 『轻量级』虚拟化 不存在真正的『Docker容器』运行在宿主机里面，Docker只是在创建进程时，加上各种不同的Namespace参数 真正对隔离环境负责的是宿主机操作系统，而非Docker Engine 容器化后的用户应用，依然还是宿主机上的普通进程 相对于VM的优势：敏捷 + 高性能 基于Linux Namespace劣势：隔离不彻底 多个容器之间使用的还是同一个宿主机的操作系统内核 低版本的Linux宿主机不能运行高版本的Linux容器 容器给应用暴露出来的攻击面是很大的 – Seccomp（对容器内部发起的系统调用做过滤拦截，影响容器性能） 在Linux内核中，很多资源和对象是不能被Namespace化的，如时间 Namesp...
猜拳设计
需求概要用户消费若干金币后排队，N人组队成功后开始猜拳，M轮PK后决出最终胜利者 轮次分布数理预测 实际分布 概要设计用例图 部署图 状态图用户阶段 数据状态 数据模型
任务系统 - 性能调优
说明调优背景 任务系统是一个运行多年且高度抽象的核心营收系统 业务高峰期出现频繁GC，导致Kafka消息消费延迟的情况，影响线上业务 经JVM参数调优后，效果提升不明显，依然无法满足业务需求，需要专项深入优化，降低内存分配的速度 主要挑战 代码高度抽象且迭代多年，存在比较陡峭的理解曲线 调优过程不能影响线上业务，因此不能采用会触发STW的工具，如HeapDump等 调优思路 不直接关注代码架构设计等静态指标，直接采样线上系统的运行数据 从采样数据中得出剩余可调优空间的TopN问题，针对问题进行分析优化后再次上线，进入下一轮调优迭代 调优N次后，当剩余可调优空间不大或者性价比不高时（问题域趋向于收敛），即结束调优迭代 采样时间 Java Flight Recorder 均为10分钟 采样文件大小与采样时间基本是O(N)的关系，不适合长时间采样，且本案例中内存分配的Top 5基本不变 Async Profiler 调优迭代为10分钟，最后一次采样为7天 采样文件大小与采样时间基本是O(1)的关系，可以长时间采样 调优迭代采样10分钟是为了快速确定TopN问题，加速调优迭代 最后一次采样为7...
