草办的学习记录

1.3kubernetes核心架构_kubernetes生产化实践之路

1.2.1、对象的通用设计原则kubernetes在设计对象时遵循如下原则：1、kubernetes 将业务模型化，对象的操作都是以API的形式发布出来的，因此API 设计都是声明式2、控制器的行为应该是可重入和幂等的，通过幂等的控制器使得系统一致朝用户期望状态努力，且结果稳定。（可重入就是说某个线程已经获得某个锁，可以再次获取锁而不会出现死锁。）3、所有对象应该是互补和可组合的，而不是简单的封装，通过组合关系构建的系统，通常能保持很好的高内聚，松耦合特性4、API操作负责度应该与对象数量成线性

云原生：将应用程序构建为微服务，并将其运行在完全动态地利用云计算模型优势的容器编排平台上的方法。云原生主要关注的是如何创建和部署程序，而不是运行在哪里。设计云原生应用可以从如下考虑：松耦合的微服务：按照业务功能设计成微服务，之间通过轻量级协议通信（例如HTTP）无状态且可规模化部署故障的容忍性和弹性：跨数据中心、跨云厂商部署时，单个服务部分实例异常不影响整体服务的质量1.1、云计算的变革物理机–虚拟机–容器化1.1.2、虚拟化时代1.基础架构即服务（Infrastructure a

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。一、隔离上节说明了：Namespace技术实际上修改了应用进程看待整个计算机“视图”，即它的视线被操作系统限制，只能看到某些指定的内容。对于宿主机来说，这些被隔离了的进程和其他进程并没有太大的区别。在这个虚拟机和容器的技术对比图中，不应该把Docker Engine 或者任何容器管理工具放在跟Hypervisor 相同的位置。因为他们并不像Hypervisor 那样对应用的隔离环境负责，也不会创建任何实体的容器，真正对隔离环境负责的是宿.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。容器本身没有价值，有价值的是容器编排。进程：一个程序运行起来后的计算机执行环境的总和。 一个程序被执行起来，它就从磁盘上的二进制文件，变成了计算机内存中的数据，寄存器里的值，堆栈中的指令，被打开的文件，以及各种设备的状态的信息集合。容器的核心技术：通过约束和修改进程的动态表现，从而为其创造出一个边界。Cgroups 技术是用来制造约束的主要手段；Namespace 技术用来修改进程视图的主要手段==在容器中可以看到进程的PID 是从.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。一、问题回顾什么情况下使用perf工具的，perf工具给我们带来了哪些信息？在调试网路延时的时候，我们使用了 ebpf 的工具之后，发现了节点上一个 CPU，也就是 CPU32 的 Softirq CPU Usage（在运行 top 时，%Cpu 那行中的 si 数值就是 Softirq CPU Usage）时不时地会增高一下。在发现CPU Usage 异常增高的时候，肯定需要排查是什么程序导致的，这个时候就用到了 perf。抓取数据，.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。一、问题背景虚拟机迁移到了 Kubernetes 平台上。迁移之后，用户发现他们的应用在容器中的出错率很高，相比在之前虚拟机上的出错率要高出一个数量级。分析了应用程序的出错日志，发现在 Kubernetes 平台上，几乎所有的出错都是因为网络超时导致的。经过网络环境排查和比对测试，我们排除了网络设备上的问题，那么这个超时就只能是容器和宿主机上的问题了。在虚拟机中的出错率是 0.001%，而在容器中的出错率是 0.01%~0.04%。偶发.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。下面说下容器安全的模块。容器的安全很大程度由容器的架构特性决定的：比如容器与宿主机共享Linux 内核，通过Namespace来做资源的隔离，通过 shim/runC 的方式来启动等。这些容器架构特性，在选择使用容器之后，作为容器的用户，其实没有多少能力去对架构层面做安全上的改动了。你可能会说用Kata Container、gVisor 就是安全“容器”了。不过，Kata 或者 gVisor 只是兼容了容器接口标准，而内部的实现完全是另外.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。上一节说了网络接口配置中的，veth 的接口配置方式，是大部分容器缺省用的网络配置方式。veth 的方式：一个数据包要从容器里发送到宿主机外，需要先从容器里的eth0（veth_container）把包发送到宿主机上 veth_host ，然后再在宿主机上通过nat或者路由的方式，经由宿主机上的eth0 向外发送。...

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。下面了解下容器网络不通了怎么调试。一、问题再现在容器中ping 公网地址不通；在宿主机上是可以的。# docker run -d --name if-test centos:8.1.1911 sleep 36000244d44f94dc2931626194c6fd3f99cec7b7c4bf61aafc6c702551e2c5ca2a371# docker exec -it if-test bash [root@244d44f9.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。今天了解下和 Network Namespace 相关的一个问题，容器中的网络参数。一、问题再现容器中运行的应用程序，如果需要用到 tcp/ip 协议栈的话，常常需要修改一些内核中网络协议栈的参数。很大一部分网络参数都在 /proc 文件系统下的 /proc/sys/net/ 目录里。内核网络相关的参数1、直接到/proc 文件系统下的/proc/sys/net/ 目录里对参数做修改2、或者使用sysctl 工具来修改先在宿主机.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。Linux 中两种I/O模式：Direct I/O，Buffered I/O模式Buffered I/O 是Linux的系统调用 write() 缺省模式。这种模式的write(）函数调用返回要快一些，使用的更普遍一些。当使用Buffered I/O的应用程序从虚拟机迁移到容器后，多了Memory Cgroup的限制后，write（）写相同大小的数据块花费的时间，波动延时比较大。一、问题再现场景：从文件中每次读取一个64KB大小的数据.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。一、场景再现运行 代码 运行一下make image来做一个带 fio 的容器镜像，用来测试磁盘文件读写性能的工具。mkdir -p /tmp/test1docker stop fio_test1;docker rm fio_test1docker run --name fio_test1 --volume /tmp/test1:/tmp registery/fio:v1 fio -direct=1 -rw=write -ioengi.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。把 Linux 从 ubuntu18.04 升级到 ubuntu20.04 之后，在容器里用 fio 这个磁盘性能测试工具，在 ubuntu 20.04 宿主机上的容器中文件读写的性能只有 ubuntu18.04 宿主机上的 1/8 左右了。一、问题再现先启动一个 ubuntu18.04的虚拟机，Linux内核版本是4.15。虚拟机上用命令 docker run -it ubuntu:18.04 bash 启动一个容器接着容器里运行f.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。swap空间：它就是一块磁盘空间，当内存写满的时候，就可以把内存中不常用的数据暂时写到这个 swap 空间上，这样一来内存空间就可以释放出来，用来满足新的内存申请的需求。它的好处是可以应对一些瞬时突发的内存增大需求，不至于因为内存一时不够而触发OOM killer，导致进程被杀死。那么容器里使用 swap 有什么影响呢？一、问题再现在一个有swap的机器上启动一个容器，设置好memory cgroup 限制。创建swap的命令：.

本文仅作为学习记录，非商业用途，侵删，如需转载需作者同意。上一节我们知道，如果容器使用的物理内存超过了 memory.limit_in_bytes，容器中的进程会被 OOM Killer 杀死。不过在有一些容器使用场景中，容器应用有很多文件读写，你会发现整个容器的内存使用量已经接近 Memory Cgroup 上限值了，但是在容器中再申请内存，还是可以申请出来，并没有发生OOM。一、问题再现测试使用的代码：https://github.com/chengyli/training/tree/ma.