目前我们所提到的容器技术、虚拟化技术(不论何种抽象层次下的虚拟化技术)都能做到资源层面上的隔离和限制。
Linux Namespace 是 Linux 提供的一种内核级别环境隔离的方法。这种隔离机制和 chroot 很类似,chroot 是把某个目录修改为根目录,从而无法访问外部的内容。Linux Namesapce 在此基础之上,提供了对 UTS、IPC、Mount、PID、Network、User 等的隔离机制,如下所示。
Linux Namespace 是 Linux 提供的一种内核级别环境隔离的方法。用官方的话来说,Linux Namespace 将全局系统资源封装在一个抽象中,从而使 namespace 内的进程认为自己具有独立的资源实例。这项技术本来没有掀起多大的波澜,是容器技术的崛起让他重新引起了大家的注意。
在本文中,我们将继续上周关于 PID 命名空间的讨论(并扩展我们正在进行的关于命名空间的系列文章)。PID 命名空间的一个用途是实现一个进程包(容器),其行为类似于一个自包含的 Linux系统。init 进程是传统系统和 PID 命名空间容器的关键部分。因此,我们将研究 init 进程的特殊角色,并着重于它与传统 init 进程不同的几个方面。此外,我们还将研究命名空间 API 应用于 PID 命名空间时的一些其他细节。
Linux Namespace是Linux提供的一种内核级别环境隔离的方法。很早以前的Unix有一个叫chroot的系统调用(通过修改根目录把用户jail到一个特定目录下),chroot提供了一种简单的隔离模式:chroot内部的文件系统无法访问外部的内容。Linux Namespace在此基础上,提供了对UTS、IPC、mount、PID、network、User等系统资源的隔离机制。在此机制下,这些系统资源不再是全局性的,而是属于特定的Namespace。每个Namespace里面的资源对其他Namespace都是透明的。要创建新的Namespace,只需要在调用clone时指定相应的flag。Linux Namespaces机制为实现基于容器的虚拟化技术提供了很好的基础,LXC(Linux containers)就是利用这一特性实现了资源的隔离。不同container内的进程属于不同的Namespace,彼此透明,互不干扰。
我的回答基本上是一句废话,因为只要你知道点网络的基础知识,肯定知道这种情况要走三层路由。
命名空间将全局系统资源包装在一个抽象中,使得命名空间中的进程认为它们拥有独立的资源实例。命名空间可用于多种目的,最重要的是实现容器,一种轻量级虚拟化技术。本系列的第二篇文章将看一下命名空间的一些细节和 API。本系列中的第一篇文章对命名空间进行了总览。本文将看一下命名空间的 API 中的一些细节,并在一些例子中展示运行中的 API。
首先,先提一下Namespace是什么。最早知道这个名词是在学习C++语言的时候。由于现在的系统越来越复杂,代码中不同的模块就可能使用相同变量,于是就出现了Namespace,来对全局作用域进行划分。
学习一下linux kernel namespace的代码还是很有必要的,让你对docker容器的namespace隔离有更深的认识。我的源码分析,是基于Linux Kernel 4.4.19 (https://www.kernel.org/pub/linux/kernel/v4.x/patch-4.4.19.gz)版本的,由于namespace模块更新很少,因此其他相近版本之间雷同。User namespace由于与其他namespaces耦合在一起,比较难分析,我将在后续再作分析。 Kernel,Nam
参考资料: 自己动手写docker-4 https://juejin.im/post/5c2b495af265da6134388142 使用golang理解Linux namespace(四)-clone前的初始化 https://here2say.com/38/
绿盟科技研究通讯曾经发表过容器逃逸的技术文章《【云原生攻防研究】容器逃逸技术概览》[1],该文中探讨了已有的容器逃逸技术。本文将沿着上文的思路,主要从Linux内核漏洞的角度对容器逃逸进行深度介绍,包括攻击原理、自动化利用和防御思路等内容。
这个告警信息说明 kube-proxy 容器被 throttling 了,然而查看该容器的资源使用历史信息,发现该容器以及容器所在的节点的 CPU 资源使用率都不高:
runc/libcontainer/configs/config.go中定义了container对应的Namespaces。另外对于User Namespaces,还定义了UidMappings和GidMappings for user map。 // Config defines configuration options for executing a process inside a contained environment. type Config struct { ... /
提供了对UTS、IPC、mount、PID、network、User等的隔离机制。
当我们使用Ptrace方式跟踪一个进程时,目标进程会记录自己被谁跟踪,可以查看/proc/pid/status看到这个信息,下图展示的是使用ida进行调试的情况。
顾名思义,veth-pair 就是一对的虚拟设备接口,和 tap/tun 设备不同的是,它都是成对出现的。一端连着协议栈,一端彼此相连着。如下图所示:
线上排查pod 问题一般有两种方式,kubectl log 或者 kubectl exec 调试。如果你的 log 写不够优雅,或者需要排除网络问题必须进容器,就只能 exec 了。
继续我们的命名空间系列文章,本文看一下用户命名空间,大部分实现于 Linux 3.8。(剩余的工作是 XFS 和其它文件系统中的一些改动;后者合并于 3.9)。用户命名空间与用户和组 ID 相映射。这意味着一个进程在某个用户命名空间内的用户和组 ID 可以与用户命名空间外的不同。最重要的是,一个进程可以在一个命名空间外有一个非 0 的用户 ID ,同时在命名空间内有一个为 0 的用户 ID;换句话说,进程在一个用户命名空间外没有特权,但在用户命名空间内有 root 特权。
接触过docker的同学多多少少听过这样一句话“docker容器通过linux namespace、cgroup特性实现资源的隔离与限制”。今天我们来尝试学习一下这两个东西。
人生不是书上的故事,喜怒哀乐,悲欢离合,都在书页间,可书页翻篇何其易,人心修补何其难。——烽火戏诸侯《剑来》
用了这么久的docker,对docker的实现原理挺感兴趣的,在对Linux下docker的实现原理了解之后,我没有用过Windows下的docker,更加好奇Windows下的docker是如何实现的(它并不开源),问了问owefsad师傅,说是可能用到了hyperV,那么可能类似Vmware吗?不知道啊。
容器已经席卷全球了。听到这个术语时,无论您想到Kubernetes,Docker,CoreOS,Silverblue还是Flatpak,很明显,现代应用程序都在容器中运行,以提供便利、安全性和可伸缩性。
集装箱已经席卷全球了。听到这个术语时,无论您想到Kubernetes,Docker,CoreOS,Silverblue还是Flatpak,很明显,现代应用程序都在容器中运行,以提供便利、安全性和可伸缩性。
在《[apue] 进程控制那些事儿 》一文中,曾提到进程 ID 并不是唯一的,在整个系统运行期间一个进程 ID 可能会出现好多次。
接着前两篇命名空间文章,现在看一下 PID 命名空间。与 PID 命名空间相关的全局资源就是进程 ID 数字空间。这意味着在不同 PID 命名空间中的进程可以有相同的进程 ID。PID 命名空间实现的容器可在主机之间迁移,并保持容器内的进程 ID 不变。
The purpose of this post is to explain how to configure kernel parameters on Red Hat (RHEL/CentOS) and Oracle Linux (OL) systems using the sysctl utility. The sysctl utility (/sbin/sysctl) allows (privileged) users to query and modify kernel parameters during runtime. The utility is common to most Linux distributions, however, subtle differences may exist between distributions e.g. RHEL/OL and SuSE. Parameters that can be viewed/modified are those exposed via procfs filesystem /proc/sys. The dot(“.”) notation is used when setting in a configuration file.
Namespace 是 Linux 内核的一个特性,该特性可以实现在同一主机系统中,对进程 ID、主机名、用户 ID、文件名、网络和进程间通信等资源的隔离。Docker 利用 Linux 内核的 Namespace 特性,实现了每个容器的资源相互隔离,从而保证容器内部只能访问到自己 Namespace 的资源。
在前面的三次分享中,我分别从 Linux Namespace 的隔离能力、Linux Cgroups 的限制能力,以及基于 rootfs 的文件系统三个角度,为你剖析了一个 Linux 容器
namespace(命名空间) 是Linux提供的一种内核级别环境隔离的方法,很多编程语言也有 namespace 这样的功能,例如C++,Java等,编程语言的 namespace 是为了解决项目中能够在不同的命名空间里使用相同的函数名或者类名。而Linux的 namespace 也是为了实现资源能够在不同的命名空间里有相同的名称,譬如在 A命名空间 有个pid为1的进程,而在 B命名空间 中也可以有一个pid为1的进程。
在每一个 Kubernetes 节点中,运行着 kubelet,负责为 Pod 创建销毁容器,kubelet 预定义了 API 接口,通过 GRPC 从指定的位置调用特定的 API 进行相关操作。而这些 CRI 的实现者,如 cri-o, containerd 等,通过调用 runc 创建出容器。runc 功能相对单一,即针对特定的配置,构建出容器运行指定进程,它不能直接用来构建镜像,kubernetes 依赖的如 cri-o 这类 CRI,在 runc 基础上增加了通过 API 管理镜像,容器等功能。
本文从OSI每一层缓存介绍、常见开源中间件缓存举例、TCP/IP协议栈中的缓存机制、操作系统中的缓存、访问缓存数据的时间范围统计等方面对计算机中的缓存进行详细介绍。希望对您有所帮助!
Beats是elastic公司的一款轻量级数据采集产品,它包含了几个子产品: packetbeat(用于监控网络流量)、 filebeat(用于监听日志数据,可以替代logstash-input-file)、 topbeat(用于搜集进程的信息、负载、内存、磁盘等数据)、 winlogbeat(用于搜集windows事件日志) 另外社区还提供了dockerbeat等工具。由于他们都是基于libbeat写出来的,因此配置上基本相同,只是input输入的地方各有差异。 本文按照如下的内容依次进行介绍: 背
本文中,继续上周关于用户命名空间的讨论。特别的,我们看一下更多有关与用户命名空间、capabilities 的交互及用户命名空间与其它类型的命名空间的结合。本文是命名空间系列的最后一篇。
最近一位非常热心的网友建议结合demo来分析一下goroutine的调度器,而且还提供了一个demo代码,于是便有了本文,在此对这位网友表示衷心的感谢!
对于刚接触k8s的人来说,最令人懵逼的应该就是k8s的网络了,如何访问部署在k8s的应用,service的几种类型有什么区别,各有什么使用场景,服务的负载均衡是如何实现的,与haproxy/nginx转发有什么区别,网络策略为什么不用限制serviceIP等等
命名空间是全局资源的一种抽象,将资源放到不同的命名空间中,各个命名空间中的资源是相互隔离的。
大功告成,可以正常使用drbd存储。但是这种方式不高效,所以后期我准备再次增加heartbeat当故障发生时可以完全自动完成主从切换。
鉴于目前还没有针对这个漏洞的详细分析,原作者的advisory对新手来说也很不友好,我就写了这篇文章。
https://docs.docker.com/engine/security/userns-remap/#prerequisites
如果大家有过在容器中执行 ps 命令的经验,都会知道在容器中的进程的 pid 一般是比较小的。例如下面我的这个例子。
刚开始接触 Kubernetes 时,你学到的第一件事就是每个 Pod 都有一个唯一的 IP 和主机名,并且在同一个 Pod 中,容器可以通过 localhost 相互通信。所以,显而易见,一个 Pod 就像一个微型的服务器。
一、准备工作: 1.1 6台模拟服务器: 主机名 IP 地址 角色 zhdy01 192.168.96.129 Master LVS + Keepalived zhdy02 192.168.96.130 Slave LVS + Keepalived LVS+Keepalived 192.168.96.200 vip zhdy03 192.168.96.131 Nginx server1 zhdy04 192.168.96.132 Nginx server2 zhdy05 192.168.96.133 Mas
不必太纠结于当下,也不必太忧虑未来,当你经历过一些事情的时候,眼前的风景已经和从前不一样了。——村上春树
最近发布的 Linux 内核带了一个针对内核的能力强大的 Linux 监控框架。它起源于历史上人们所说的的 BPF。
看了 《Android 的离奇陷阱 — 设置线程优先级导致的微信卡顿惨案》这篇文章,有没有觉得原来大家再熟悉不过的线程,也还有鲜为人知的坑?除此之外,微信与线程之间还有很多不得不说的故事,下面跟大家分享一下线程还会导致什么样的内存问题。 [anon:thread stack guard page] 在分析虚拟内存空间耗尽导致的 crash 问题时,我们在 /proc/[pid]/maps 中发现了新增了不少跟以往不一样 case,内存中充满了大量这样的块: 从 map entry 的名字与内存大小和权
今天翻了一个PVE集群的日志,发现一个持续报错,单一错误居然把/var/log/syslog撑到了600M,主要就一个错误
背景 国外安全研究员champtar[1]在日常使用中发现Kubernetes tmpfs挂载存在逃逸现象,研究后发现runC存在条件竞争漏洞,可以导致挂载逃逸[2]。 关于条件竞争TOCTOU和一些linux文件基础知识可见这篇文章《初探文件路径条件竞争 - TOCTOU&CVE-2019-18276》[3]。 CVE-2021-30465在Redteam的研究者视角中比较鸡肋,因为需要K8S批量创建POD的权限。但在产品安全的视角恰恰相反,针对Caas(Container as a service)类
CrowdStrike的云威胁研究团队在CRI-O(一个支撑Kubernetes的容器运行时引擎)中发现了一个新的漏洞(CVE-2022-0811),被称为“cr8escape”[1]。攻击者在创建容器时可以从Kubernetes容器中逃离,并获得对主机的根访问权,从而可以在集群中的任何地方移动。调用CVE-2022-0811可以让攻击者对目标执行各种操作,包括执行恶意软件、数据外溢和跨pod的横向移动。CRI-O被很多程序默认使用,影响范围较大,CVE评分8.8[2]。影响范围为CRI-O 版本 > 1.19.0。该漏洞已在3月15日发布的CRI-O 版本1.19.6、1.20.7、1.21.6、1.22.3、1.23.2中修复,受影响用户可以及时升级更新。
领取专属 10元无门槛券
手把手带您无忧上云