cgroup

kubelet 参数详解 基本参数 --allow-privileged=true #允许容器请求特权模式 --anonymous-auth=false #不允许匿名请求到 kubelet 服务（默认 true ） --authentication-token-webhook=true #使用 TokenReview API 来确定不记名令牌的身份验证 --authorization-mode=Webhook #kubelet 服务的授权模式，Webhook 模式使用 SubjectAccessReview API 来确定授权。(默认“AlwaysAllow”) --cadvisor-port=0 #本地 cAdvisor 端口（默认 4194） --cgroup-driver=cgroupfs #kubelet 用来操作主机上的 cgroups 驱动，可选值有：“cgroupfs”和“systemd”（默认“cgroupfs”） --client-ca-file=/etc/kubernetes/pki/ca.crt #集群ca证书 --cluster-dns=10.96.0.10 #DNS 服务器的IP地址列表，逗号分隔。 --cluster-domain=xxx.xxx.xxx #集群域名, kubelet 将配置所有容器除了主机搜索域还将搜索当前域。 --cni-bin

原文地址： https://www.yangcs.net/posts/understanding-resource-limits-in-kubernetes-cpu-time/ 在关于 Kubernetes 资源限制的系列文章的 第一篇文章 中，我讨论了如何使用 ResourceRequirements 对象来设置 Pod 中容器的内存资源限制，以及如何通过容器运行时和 linux control group（ cgroup ）来实现这些限制。我还谈到了 Requests 和 Limits 之间的区别，其中 Requests 用于在调度时通知调度器 Pod 需要多少资源才能调度，而 Limits 用来告诉 Linux 内核什么时候你的进程可以为了清理空间而被杀死。在这篇文章中，我会继续仔细分析 CPU 资源限制。想要理解这篇文章所说的内容，不一定要先阅读上一篇文章，但我建议那些工程师和集群管理员最好还是先阅读完第一篇，以便全面掌控你的集群。 1. CPU 限制 正如我在上一篇文章中提到的， CPU 资源限制比内存资源限制更复杂，原因将在下文详述。幸运的是 CPU 资源限制和内存资源限制一样都是由 cgroup 控制的，上文中提到的思路和工具在这里同样适用，我们只需要关注他们的不同点就行了。首先，让我们将 CPU 资源限制添加到之前示例中的 yaml： resources:

一、docker容器技术与传统虚拟化技术的比较 Docker容器技术是一个与传统的虚拟化技术有些本质上的差别，传统的虚拟化技术，是站硬件物理资源的基础上，虚拟出多个OS，然后在OS的基础上构建相对独立的程序运行环境，而Docker则是在OS的基础上进行虚拟，所以，Docker轻量很多，因此其资源占用、性能消耗相比传统虚拟化都有很大的优势。 docker容器很快，启动和停止可以在秒级实现，比传统的虚拟化技术要快很多，docker核心解决的问题是利用容器来实现类似VM的功能，从而节省更多的硬件资源，docker容器除了运行其中的应用之外，基本不消耗额外的系统资源，从而在保证性能的同时，减小系统开销，同时，它还可以达到“一次封装，到处运行”的目的。 Docker和传统虚拟化的区别如下： docker和传统虚拟化的架构上的区别如下： 二、NameSpace和Cgroup的概念与作用 Docker中有三个核心概念，分别是镜像、容器、仓库。而镜像的概念主要就是把运行环境和业务代码进行镜像打包，每个镜像都会存在多个“层”，镜像层都是只读的，不能往里写数据，如果想要写，就需要在其基础之上启动成一个容器， 在容器层，我们是可写的。 在镜像的多个“层”中，有一个busybox的概念，我将它理解为欺骗层。 虚拟化的技术就是来解决宿主机与虚拟机之间的耦合问题（简称“解耦”），传统虚拟化是属于完全解耦的

异常【kubelet cgroup driver：cgroupfs跟docker cgroup driver：systemd不一致】 异常描述 error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd" 启动kubelet时 #启动kubelet service kubelet start #查看kubelet日志 journalctl -f -u kubelet 提示如下错误 10月 11 20:05:18 server03 kubelet[15984]: error: failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd" 10月 11 20:05:18 server03 systemd[1]: kubelet.service: main process exited, code

通过cgroup将ceph-osd进程与某一个 CPU core 绑定脚本： mkdir -p /sys/fs/cgroup/cpuset/ceph # cup number : 0,1,2,3 = 0-3 echo 0,4 > /sys/fs/cgroup/cpuset/ceph/cpuset.cpus # NUMA node echo 0 > /sys/fs/cgroup/cpuset/ceph/cpuset.mems osd-pid-list=$(ps aux | grep osd | grep -v grep | awk '{print $2}') for osd-pid in $(osd-pid-list) do echo $(osd-pid) > /sys/fs/cgroup/cpuset/ceph/cgroup.procs done 来源： https://www.cnblogs.com/wangjq19920210/p/11428042.html

虚拟机默认磁盘类型 scsi硬盘 分区符MBR(512字节) 三部分组成： 引导程序： 446字节（bootloader） 分区表： 64字节 魔数： 2字节（55AA） 分区： 主分区+扩展分区（扩展分区之上建立了逻辑分区） 1. 即扩展分区是逻辑分区的资源池，逻辑分区的总大小即扩展分区大小 2. 扩展分区不能直接使用，扩展分区必须首先创建成逻辑分区才能使用 查看磁盘： ls /dev/sd* 例子1：/dev/sda1 表示第一块系统识别到scsi硬盘的第一个分区 文件系统： EXT4：是centos6默认的文件系统 XFS： 是centos7系统默认的文件系统 fdisk分区演示–创建主分区 第一步：关机添加磁盘 略 第二步:查看磁盘 [root@ken ~]# ls /dev/sd* /dev/sda /dev/sda1 /dev/sda2 /dev/sdb 第三步：fdisk创建主分区 [root@ken ~]# fdisk /dev/sdb Welcome to fdisk (util-linux 2.23.2). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Device does not

Docker暴露容器方法 第一种：将容器中的一个端口映射成宿主机中的一个随机端口 第二种：将容器中的一个端口映射成宿主机中的一个端口 第三种：将容器中的一个端口映射成宿主机中的一个特定网卡上的随机端口 第四种：将容器中的一个端口映射成宿主机中的一个特定网卡上的一个端口 【使用多次-p选项可以实现暴露多个端口】 Docker端口映射的四种方法使用演示 第一种：将容器中的一个端口映射成宿主机中的一个随机端口 下面的操作确保虚拟机是在桥接模式 第一步：下载httpd镜像 [root@ken ~]# docker pull httpd [root@ken ~]# docker image ls REPOSITORY TAG IMAGE ID CREATED SIZE httpd latest 2a51bb06dc8b 12 days ago 132MB redis latest 55cb7014c24f 5 months ago 83.4MB 第二步：启动httpd容器 –name: 指定容器名 -d: 后台运行 -P: 大写的P，映射随机端口(暴露容器内所有端口，映射到宿主机的随机端口) –rm: 表示退出容器时删除容器 [root@ken ~]# docker container run --name httpd1 -d -P --rm httpd 第三步：查看端口

部署环境 # 操作系统：CentOS Linux release 8.0.1905 (Core) # kubelet 版本： v1.14.0 # runc版本：v1.0.0-rc9 # crictl 版本：v1.16.1 #crio版本：v1.15.2 #conmon版本：v2.0.1 # cni版本：v0.8.2 # 网络插件： kube-router #工作目录： /apps # 二进制文件目录： /usr/bin # cni 目录：/apps/cni # 工作节点：win10 on Ubuntu 19.10 # 工作目录：/mnt/g/work/crio # 节点IP：192.168.2.196 # 节点名：node05 准备所需二进制文件 mkdir -p /mnt/g/work/crio cd /mnt/g/work/crio wget https://github.com/opencontainers/runc/releases/download/v1.0.0-rc9/runc.amd64 wget https://github.com/kubernetes-sigs/cri-tools/releases/download/v1.16.1/crictl-v1.16.1-linux-amd64.tar.gz wget https://github.com/cri-o

十、Kubernetes实践篇 10.1) Kubernetes安装三种方式（官方提供） 10.1.1）minikube Minikube是一个工具，可以在本地快速运行一个单点的Kubernetes，尝试Kubernetes或日常开发的用户使用。不能用于生产环境。 官方文档： https://kubernetes.io/docs/setup/minikube/ 10.1.2）kubeadm kubeadm可帮助你快速部署一套kubernetes集群。kubeadm设计目的为新用户开始尝试kubernetes提供一种简单的方法。目前是Beta版。 官方文档： https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/ https://kubernetes.io/docs/setup/independent/install-kubeadm/ 10.1.3）二进制包 从官方下载发行版的二进制包，手动部署每个组件，组成Kubernetes集群。目前企业生产环境中主要使用该方式。 下载地址： https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.11.md#v1113 10.2) Kubernetes安装规划 10.2.1）基本资源 操作系统

背景 从 Linux 内核 2.6.25 开始，CGroup 支持对进程内存的隔离和限制，这也是 Docker 等容器技术的底层支撑。 使用 CGroup 有如下好处： 在共享的机器上，进程相互隔离，互不影响，对其它进程是种保护。 对于存在内存泄漏的进程，可以设置内存限制，通过系统 OOM 触发的 Kill 信号量来实现重启。 CGroup 快速入门 默认挂载分组 Linux 系统默认支持 CGroup, 而且默认挂载所有选项，可以使用 mount -t cgroup 来查看： $ mount -t cgroup cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs