系统基础安全实验

创建出的容器内存大小与虚拟机一致
docker run -it --name vm1 ubntu
查看内存状态free -m
对比虚拟机和容器

查看容器进程的namespace

可以看到vm1容器的namespace有六个
查看cgroup进程的路径

在/sys/fs/cgroup下

依次查看cpu，内存和容器的目录下的文件

在memory目录下新建目录时直接会从上级目录继承
在memory目录下创建一个文件夹x1

进入到x1文件目录下查看

对比可以看到x1文件目录下的文件基本与其父目录memory文件内容一致
因为没有人为的创建文件
对比创建容器的id与其原名称的差距
在创建容器的时候会在/sys/fs/cgroup/memory/docker这个目录底下生成相应容器id的文件夹
创建容器并查看容器的id

在/sys/fs/cgroup/memory/docker文件夹下查看容器的原始id

对比两者不难发现，在查询的容器的id只是其真实id的一部分

在其id的文件夹下查看对于内存的限制会看到一个数字，不过这么大的数字基本就是接近无限的意思

对cpu进行资源限制

实验环境是只有一个cpu
与memory文件夹一样，在cpu目录下创建一个x1文件夹，来继承父目录cpu下的文件配置

查看其目录下的几个文件了解cpu对于系统的限制，其中数值-1表示对系统没有限制

cat cpu.cfs_period_us

##查看cpu限制的长度

 cat cpu.cfs_quota_us

##对于时间的限制

dd if=/dev/zero of=/dev/null &

##占用cpu

top

##查看cpu的占有率

此时cpu已经被沾满了
对cpu的资源进行限制
在x1
将cpu限制的长度修改为20000
将20000这个数值导入到限制cpu长度的文件夹

发现现在cpu的占用率还是在100%徘徊

将cpu的PID导入到tasks文件中，并再次查看

可以看到cpu的占有率被很好的控制在20%左右
将对应的进程杀死就在tasks文件里面看不到PID了

在容器环境下对cpu进行限制
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:

• kind: ServiceAccount
  name: admin-user
  namespace: kube-system

apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system

apiVersion: v1
kind: ServiceAccount
metadata:
name: admin-user
namespace: kube-system

---

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin-user
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:

• kind: ServiceAccount
  name: admin-user
  namespace: kube-system