2

Pod Manager 容器

 1 year ago
source link: https://blog.51cto.com/u_16170308/7090969
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Pod Manager 容器

精选 原创

容器

#所见及所得并且让内容的转移更加便捷,不受依赖性的干扰,所以可以总结出,容器是一种自包含的软件打包技术(一次构建,随处运行)

#自包含:软件本身的文件和软件所需的依赖环境

开发:

容易意味着可以对环境隔离并且实现重复性;对于开发来说,只是需要为应用创建一次运行环境,然后打包成容器就可以在其他设备上运行。并且容器的环境所在的Host环境是完全隔离开来的,类似虚拟机,但是相比于虚拟机更加轻便。

运维:

运维只是需要配置标准的运行环境,设备即可运行任何容器,无需再去关注真的应用环境怎么部署,插件怎么安装等问题;消除了开发,测试以及生产环境的不一致性。

容器&&虚拟机

容器:

Pod Manager 容器_podman

#容器是一个没有灵魂的操作系统,因为它没有属于自己单独的内核,所以容器如果想使用CPU和硬盘,就必须得通过kernel内核来进行访问,以此看出对于宿主机而言,一个容器就是一个进程。

虚拟机:

Pod Manager 容器_docker_02

#由上图可以看出,虚拟机是有自己的硬件,自己的内核,很多情况下是没有直接用到我们底层自己的内核,所以在这种场景下,虚拟机的隔离性是优于容器的。

虚拟机:重量级的虚拟化,对于虚拟机来讲是基于内核的隔离,对于每一个虚拟机都有一个完整的独立内核和虚拟硬件。

容器:轻量级的虚拟化,实际上只是虚拟出来了用户空间,但是没有内核空间,以此来实现应用上面的隔离==》只能运行宿主机是Linux的操作系统上(因为Linux的内核是开源的,而Windwos是不开源的)

安全:但从安全方面来考虑,虚拟机的安全性和隔离性是高于容器;是因为虚拟机基于内核来隔离,而容器仅仅只是基于进程来隔离。

性能:虚拟机如果需要将资源存储到硬盘上那么会经历==>真实内核==>虚拟硬件==>虚拟内核==》应用,这相对于容器而言会多了一层时间损耗,所以可以总结得出容器复用了物理机的内核所以性能会更好。

镜像的大小:因为虚拟机包含了一个完整的操作系统,而容器里面只有所需要运行的软件,以及软件的依赖等等,除此之外没有其他东西,所以容器的镜像远远小于虚拟机的镜像。

镜像的标准:在虚拟化的场景中,最初各个厂商只能兼容自己的虚拟化格式,而后来出现了开放虚拟机格式,也叫通用型格式 ova/ovf ,容器则是基于OCI的标准来进行构建,因此大部分容器引擎都可以使用。

创建速度:虚拟机的创建速度较慢,而容器则是以秒级为单位

运行速度:虚拟机较慢,启动是以分钟级为单位,而容器则是秒级启动

资源粒度:虚拟化节点单节点运行数量一般为上百个,而容器单节点可以达到上万个

总结:虚拟机比较侧重于一些对于安全,硬件都有较高要求的场景,而容器则侧重于一些负载类的应用和轻应用

容器的核心:

(1)namespace 命名空间==》其最大作用在于隔离

(2)cgroup 资源控制组 ==》用来限制容器所使用的cpu和内存

(3)chroot 锁定根文件系统 ==》用来隔离容器之间对于物理机的访问限制

#从这里就可以看出,为什么容器只能运行在linux操作系统之上呢?因为容器本身就是通过linux的内核特性来构建出来的

podman

<<EOF
podman与docker一样是一种新的容器工具,它与docker最大的区别就是podman是没有服务端的,docker是典型
的c/s架构,而podman仅仅只是一个容器工具而已;
因为podman也是基于OCI的标准去做的,所以docker能够运行的镜像podman也能运行,它最大程度的去兼容了do
cker。
EOF

podman与docker对比:

架构:podman仅仅只是一个工具,无需去运行服务;而docker则是依赖于dockerd服务的运行。

权限:dockerd依赖于root权限去运行,所以普通用户无法去运行容器(新版可以),podman是无根容器(在某种层面安全系数更高),也就是在podman的世界里面任何一个用户都可以运行容器。

systemd:docker 容器不能与systemd继承,所以无法通过服务实现管理容器;而podman原生就支持与systemd集成,可以将容器当做服务来管理。

镜像:podman是一个模块化的产物,有专门构建镜像的工具,也有专门去管理镜像仓库的工具,而docker则是依赖于docker daemon来实现对镜像的管理。

podman的安装:

#在redhat8中会自动安装,因为podman是一个模块化的管理工具,所以还需要安装 skopeo 的镜像检查工具和buildah创建容器镜像的工具。

Pod Manager 容器_数据_03
Pod Manager 容器_数据_04

容器镜像仓库:

仓库路径(全局配置文件):/etc/containers/registries.conf 

用户配置文件:home/$user/config/container/registries.conf(仅指定用户可以使用)

#当两个配置文件同时存在时,用户配置文件的优先级会更高

Pod Manager 容器_配置文件_05

配置仓库(在registries.conf 中操作即可)

#[registries.search] ==》镜像的搜索域,表示所有的镜像都会从registries中获取
#[registries.insecure] ==》配置不使用TLS加密,主要用于私有仓库,也就是使用http类型的仓库
#[registries.block] ==》禁用的仓库列表
Pod Manager 容器_配置文件_06

podman search ubi #搜索ubi的镜像

Pod Manager 容器_podman_07

podman pull 镜像地址 #拉去镜像

Pod Manager 容器_配置文件_08

podman images #查看下载的镜像

Pod Manager 容器_docker_09

容器的镜像仓库分类:

公共仓库(所有人都可使用):

 registry.redhat.io(需要身份验证)

 regustry.access.redhat.com (不需要验证)

 docker.io (docker 官方仓库)

 Quay.io (quay官方仓库)

私有仓库(企业内部自检或者云上自建):

**云等公有云平台

从仓库获取镜像:

podman pull <registry>[:<port>]/[<namespace>/]<name>:<tag>
#registry:port 仓库的地址(也叫注册服务器)
#namesoace 仓库的名字
#name 镜像的名字
#tag 镜像的标签,其中latest表示最新的版本

podman images #查看本地镜像

Pod Manager 容器_redhat_10

podman inspect 本机镜像 #查看镜像详细信息,查询的前提是得把镜像先拉取下来

Pod Manager 容器_docker_11

skopeo inspect docker://仓库镜像地址 #查看线上镜像详情,需注意其中镜像地址需要以 docker:// 开头,这代表OCI的镜像标准

Pod Manager 容器_redhat_12

  仓库的管理:

(1)登录到私有仓库(登录成功后即可使用这个私有仓库)

podman login registry registry.redhat.io

Pod Manager 容器_docker_13

(2)退出登录

podman logout registry.redhat.io

Pod Manager 容器_docker_14

(3)将镜像推送到私有仓库

#推送前提,私有仓库有正常登录
#第一步,先对镜像打标签
podman tag registry.access.redhat.com/ubi8:latest 私有仓库地址/标签名称
#第二步,推送
podman push 私有仓库地址/标签名称:版本号

#镜像移植

(1)对镜像进行打包

podman save -o nginx.tar docker.io/bitnami/nginx:latest

Pod Manager 容器_数据_15

(2)将.tar文件传输到所需的设备上

(3)导入.tar包

podman load < nginx.tar

Pod Manager 容器_配置文件_16

#镜像删除

podman rmi 镜像地址:版本

容器:

运行容器

podman run 镜像地址:版本 #其中 podman ps 是查看正在运行的容器 podman ps -a 是查看所有的容器

Pod Manager 容器_配置文件_17

#需注意,在容器里面跑的应用结束了,那么容器也会结束(容器为应用而生,为应用而死),如上图所示,运行的是/bin/bash ,/bin/bash 运行结束了,容器也就退出了

*保持运行容器

podman run -it 镜像路径:版本 /bin/bash #其中 -i 是已交互的形式运行这个容器,-t 是绑定一个终端

Pod Manager 容器_配置文件_18

#这个时候在使用 podman ps 来查看容器状态则为正在运行

Pod Manager 容器_podman_19

*将容器放在后台运行

podman run -d --name 容器名称 镜像名称 #将容器放在后台运行

Pod Manager 容器_配置文件_20

*创建一个容器(创建后默认不启动)

podman create -it --name demo04 镜像地址:版本 /bin/bash

Pod Manager 容器_配置文件_21

*将创建的容器启动

podman start demo04

Pod Manager 容器_配置文件_22

*停止一个容器

podman stop 容器名字

Pod Manager 容器_数据_23

*重启一个容器

podman restart demo04

Pod Manager 容器_数据_24

*挂起一个容器

podman pause demo04

Pod Manager 容器_配置文件_25

*恢复一个容器

podman unpause demo04

Pod Manager 容器_数据_26

*删除一个容器(正在运行的容器不能直接删除,需要先停止)

podman rm 容器NAEMS

Pod Manager 容器_配置文件_27

#如果需要强制删除容器,可以使用 podman rm -f NAMES 来操作

<<EOF
podman ps -aq 查询当前所有容器的ID
podman ps --filter status=状态 根据状态来对容器进行过滤
podman ps --filter status=状态 -aq 获取指定状态容器的ID
EOF

*进入已经存在的容器

podman attach NEMES #需注意,用此方式进入容器,那么操作完毕退出容器后,容器也会结束掉,因为attach会刷新容器的状态

Pod Manager 容器_配置文件_28

podman exec -it demo04 /bin/bash #i是交互式进程,t是终端,这个命令相当在容器中运行这个交互式进程,这种方式进入容器,不会让容器退出

Pod Manager 容器_podman_29

*将容器制作为镜像

Pod Manager 容器_docker_30

第一步,停止容器

podman stop demo04

Pod Manager 容器_数据_31

第二步,将其导出

podman export demo04 > demo04.tar

Pod Manager 容器_配置文件_32

第三步,将其导入到podman

podman import demo04.tar

Pod Manager 容器_docker_33

第四步,给镜像打上标签(通过IMAGE ID 打上标签即可)

podman tag IMAGE ID localhost/demo/demo:v1

Pod Manager 容器_配置文件_34

第五步,运行测试

podman run -d -it --name demo05 localhost/demo/demo:v1

podman exec -it demo05 /bin/bash

Pod Manager 容器_podman_35

无根容器(rootless==>系统必须在RHEL7.7及更高版本才可支持):

rootless 无根容器指的就是没有管理员权限的用户创建,管理运行的容器;

在无根容器上有新增一个安全层(用户层),如果容器在运行时或者业务流程协调的程序受到威胁的时候入侵者也是无法获得root权限;这种允许子用户创建的形态在高性能计算环境中是比较有利的,并且无根容器允许在嵌套容器内进行隔离(类似虚拟机嵌套的概念,在虚拟机中跑虚拟机,在容器里面跑容器)。

注:

(1)操作无根容器的子账号不能是切换过去的,也就是不允许使用 su 或 su - 的方式(这样会拿不到子用户的环境变量),必须得严格是ssh登陆的子账号

(2)无根容器只能映射1024以上的端口,因为1024以下的均为特权端口,只能给到root使用

*其常规操作方法与普通容器一致,例如 podman ps 等等

容器的存储:

*应为容器的镜像是一个只读模板,所以容器在运行的时候系统会给容器挂载一个临时的读写层,所以用户在容器内的修改,会保存在这个读写层;如果容器被删除那么这个读写层连同数据会一起被删除,因此容器中用户的数据不会保存到镜像,从这里可以看出容器属于易失性存储

持久保留数据的方式:

(1)挂载数据卷

podman volume ls #查看当前数据卷 ==》启动容器时临时读写层的数据卷也会在这里显示

Pod Manager 容器_数据_36

podman volume create volume1 #创建数据卷

Pod Manager 容器_数据_37

podman volume inspect volume1 #查看数据卷详细信息,其中Driver 为 local 表示这是一个本地目录,Mointpoint表示数据卷最终存储的位置

Pod Manager 容器_配置文件_38

podman run -d --name demo06 --volume volume1:容器中需要保存数据的路径 -p 8080:80 镜像地址:版本 #将数据卷挂载给容器使用,注意只能在容器运行时挂载,无法在已经运行的容器进行挂载

Pod Manager 容器_docker_39

#在这种情况下上传到指定路径后,文件就会保存在宿主机数据卷中,不会随着容器的结束而小时

#将文件传入已经运行的容器中

podman cp file.txt demo05:/opt

Pod Manager 容器_redhat_40

#将容器中的内容拷贝至宿主机上

podman cp demo05:/opt/file.txt .

Pod Manager 容器_podman_41

#删除数据卷

podman volume rm 数据卷名称

Pod Manager 容器_配置文件_42

(2)挂载宿主机目录

第一步:在宿主机创建目录

第二步:将目录挂载到宿主机

#通过-v 挂载对应目录即可

Pod Manager 容器_docker_43

容器的网络:

模式(通过 --network 即可指定不同类型的网络):

Pod Manager 容器_配置文件_44

host ==>使用宿主机的网络作为容器网络

bridge ==> 使用桥接网络 ==> 默认

none ==> 不使用网络

podman容器与systemd 集成:

一,root用户集成

第一步:为容器创建一个服务单元的配置文件

podman generate systemd demo05 --files --name --new

Pod Manager 容器_podman_45

#--file 生成配置文件

#--name 已容器的名称作为配置文件的名称

#--new 当容器被删除时,systemd会主动去镜像中将容器重新拉起来

第二步:将单元加载到systemd

cp 生成的服务单元配置文件 /etc/systemd/system

Pod Manager 容器_docker_46

systemctl daemon-reload #重新加载一下system即可看到服务

Pod Manager 容器_redhat_47

二,普通用户集成

普通用户集成于root用户方式一直,只是需要将生成的配置文件存放在 ~/.config/systemd/user 中再去加载配置文件即可


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK