在前面的文章中，我们已经对Pod对象进行了深入地讨论。接下来，我们一起来看Kubernetes项目最核心的功能，编排。 一、从一个例子说起 在前面讨论Pod对象时，我们做出了一个这样的总结：“容器，是进程；Pod，是操作系统”。由于容器描述应用时过于简单，因此kubernetes将容器进一步抽象、封装成了Pod。在kubernetes的世界中，通常不会直接操作Pod对象，而是由控制器完成。比如，下

在前面的文章中，我们已经深入讨论了Pod的API对象，以及Pod和Container的关系。接下来，我们先从一种特殊的Volume开始，更加深入地理解Pod对象各个重要字段的含义。 一、Projected Volume 在 Kubernetes 中，有几种特殊的 Volume，它们存在的意义不是为了存放容器里的数据，也不是用来进行容器和宿主机之间的数据交换。这些特殊 Volume 的作用，是为容器

在前面的文章中，我们详细讨论了Pod的实现原理和容器设计模式。接下来，我们来看看有关Pod对象的更多细节。 一、Pod VS 虚拟机 在 Kubernetes 项目中，最小的编排单位是Pod。将这个设计落实到 API 对象上后，容器（Container）就成了 Pod 属性里的一个普通的字段。此时，一个很自然的问题就是： 到底哪些字段属于 Pod 对象，而又有哪些字段属于 Container ？

接触过kubernetes的同学，对Pod这个概念一定不陌生。它是Kubernetes项目中最小的API对象。用更专业的术语来描述：Pod，是Kubernetes项目的原子调度单位。但我们是否思考过：我们为什么需要Pod？接下来，我们就来讨论一下这个问题。 一、从进程组说起 首先，我们登录到一台 Linux 机器里，执行一条如下所示的命令： 1$ pstree -gt 这条命令的作用，是展示当前系

在前面的文章中，我们围绕“Namespace做隔离、Cgroups做限制、Rootfs做文件系统”对Linux容器的核心实现原理展开了详细的讨论。接下来，我们通过一个实际案例对前面的内容做一次深入的总结和扩展。 一、从一个Python应用说起 在开始实践之前，我们需要准备一台 Linux 机器，并安装 Docker。这个流程可以参考Docker官网，就不在此赘述了。 这一次，我们用 Docker

todo 一、理解Mount Namespace 如下，是一个小程序，它的作用是在创建子进程时开启指定的Namespace。 12345678910111213141516171819202122232425262728293031#define _GNU_SOURCE#include <sys/mount.h> #include <sys/types.h>#include

在我们真的了解容器吗这文章中，我们讨论了Linux容器中用来实现“隔离”的技术手段：Namespace。接下来，我们一起来了解一下容器的限制机制。 一、再谈隔离 我们知道，Namespace技术实际上修改了进程能够看到的计算机“视图”，即它的“视线”被操作系统做了限制，只能“看到”某些指定的内容。但对于宿主机来说，这些被“隔离”的进程跟其他进程并没有太大区别。 此外，我们需要知道的是，Docker

我相信但凡接触过Docker的同学，一定看到过下面这张虚拟机和容器的对比图： 在这幅图的左边，画出了虚拟机的工作原理。其中，名为Hypervisor的软件是虚拟机最主要的部分。它通过硬件虚拟化功能，模拟出运行一个操作系统所需的各种硬件，比如，CPU、内存、I/O设备等；然后，它在这些虚拟的硬件上安装一个新的操作系统，即Guest OS。这样，我们的应用程序就可以运行在这个虚拟的机器中，而它所能看到

对于不同的业务场景，垃圾回收调优策略是不一样的。比如，在对内存要求苛刻的情况下，需要提高对象回收效率；在CPU使用率高的情况下，需要降低高并发时垃圾回收的频率。那么面对不同的场景，我们该如何进行调优呢？ 一、GC性能衡量指标 在进行实际的GC调优前，我们需要根据一些GC性能指标，确定具体的调优方向。常用的GC性能指标如下： 吞吐量，这里的吞吐量是指应用程序所花费的时间和系统总运行时间的比值。我们

在JVM内存分配中，我们提出了一个问题，当遇到JVM内存性能问题时，应该如何调优？接下来我们通过一个案例来回答这个问题。 一、案例场景 现模拟一个抢购接口，假设需要满足5W的并发请求，且每次请求会产生20KB对象。这里，我们可以通过千级并发创建一个1MB对象的接口来模拟万级并发请求产生大量对象的场景，具体代码如下： 12345678@RequestMapping(value = '/te