ByteCoding

基本概念 在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里的所有容器，共享的是 ...

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对外提供服 ...

容器 本质：由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能够运行标准的Co ...

文件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', port=8 ...

环境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 123456789101112131415161718192021222324 ...

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化的，如时间 Namespace ...

需求概要用户消费若干金币后排队，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天是为 ...

节拍率（HZ） 为了维护CPU时间，Linux 通过事先定义的节拍率（内核中表示为HZ） 触发时间中断，并使用全局变量Jiffies记录开机以来的节拍数 节拍率 HZ 是内核的可配选项，可设置为100、250、1000等 HZ=250，表示每秒触发250次时间中断，每发生一次时间中断，Jiffies值+1 节拍率 HZ 是内核选项，用户空间程序不能直接访问 为了方便用户空间程序，内核提供了一个空户空间节拍率USER_HZ，固定为100，即10ms 12root@ubuntu:~# grep 'CONFIG_HZ=' /boot/config-$(uname -r)CONFIG_HZ=250 /proc/stat & CPU使用率 Linux 通过 /proc 虚拟文件系统，向用户空间提供系统内部状态的信息 /proc/stat 提供的是系统的 CPU 和任务统计信息 12345# 后面10列表示不同场景下 CPU 的累计节拍数，单位是USER_HZ，即10ms，即不同场景下的 CPU 时间root@ubuntu:~# cat /pro ...

CPU 上下文 CPU 上下文 CPU 在运行任何任务前，必须的依赖环境 CPU 寄存器 CPU 内置的容量小、但速度极快的内存 程序计数器 存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置 CPU 上下文切换 切换过程 先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来 然后加载新任务的上下文到这些寄存器和程序计数器 最后再跳转到程序计数器所指的新位置，运行新任务 保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来 CPU特权等级 & 进程运行空间 & 系统调用 进程的运行空间分为内核空间和用户空间 内核空间（Ring 0） 具有最高权限，可以直接访问所有资源 用户空间（Ring 3） 只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源 进程在用户空间运行时，被成为进程的用户态；而陷入内核空间的时候，被称为进程的内核态 从用户态到内核态的转变，需要通过系统调用来完成 系统调用的过程会发生 CPU 上下文的切换 一次系统调用，发生了两次 CPU ...