ByteCoding

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 ...

uptime1分钟、5分钟、15分钟 12$ uptime 07:40:47 up 24 min, 2 users, load average: 0.14, 0.14, 0.19 平均负载 单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和CPU使用率并没有直接关系 所谓可运行状态的进程，是指正在使用CPU或者正在等待CPU的进程 也就是我们常用ps命令看到的，处于R状态（Running或Runnable）的进程 不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的 比如最常见的是等待硬件设备的I/O响应 当一个进程向磁盘读写数据时，为了保证数据的一致性 在得到磁盘回复前，它是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态 也就是我们在ps命令中看到的D状态（Uninterruptible Sleep，也称为Disk Sleep）的进程 不可中断状态实际上是系统对进程和硬件设备的一种保护机制 理想情况平均负载 = CPU个数 12$ grep 'model name' /p ...