ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > 数据库开发技术 > 轻量级容器管理工具Container

轻量级容器管理工具Container

原创 数据库开发技术 作者：步步运维步步坑 时间：2024-07-31 11:03:38 0 删除 编辑

在Kubernetes的发展历程中，从版本v1.20起就预示了一个重要的转变，即逐步减少对Docker Engine特定组件dockershim的直接依赖。这一变化最终在Kubernetes v1.24版本中正式体现，标志着Docker作为Kubernetes原生容器运行时的角色被正式弃用。取而代之的是，Kubernetes转而采用更为轻量、高效且设计更为通用的containerd作为其核心容器运行时解决方案。

containerd，这一跨平台的守护进程，不仅限于Linux环境，同样支持Windows，为集群中的容器提供了全面的生命周期管理能力。它负责从镜像的拉取、存储与管理，到容器的创建、执行与监控，再到底层存储和网络附加资源的管理等一系列核心功能。通过这一转变，Kubernetes旨在提升其容器化应用的部署效率、资源利用率以及可扩展性，同时减少了对特定容器技术的依赖，促进了生态系统的多样性和开放性。


由来

在2013年Docker公司成功推出Docker产品后，其迅速在全球范围内引发了技术革命，对众多技术栈产生了深远影响。Google公司，作为技术领域的巨头，敏锐地察觉到自家内部广泛应用的Borg系统面临着来自Docker新兴势力的挑战与潜在的市场地位动摇。鉴于此，Google主动伸出橄榄枝，提议与Docker公司携手合作，共同开发一款开放源代码的容器运行时技术，旨在成为Docker生态系统中的核心依赖组件。然而，这一合作倡议并未获得Docker公司的积极回应，双方的合作尝试因此搁浅。


面对合作的失利，Google并未放弃推动容器技术标准化的愿景。随后，它联合了Red Hat、IBM等业界重量级企业，采取了一种更为策略性的方式——通过游说Docker公司，成功促成了Docker将其核心的容器技术组件libcontainer贡献给Open Container Initiative（OCI）这一开源组织。这一举措不仅体现了行业巨头间的合作与妥协，也标志着容器技术迈向了更加开放、标准化的新阶段。libcontainer在加入OCI后，被重新命名为runC，成为了构建容器运行时环境的关键基石，进一步推动了容器技术的普及与发展。


为了在未来技术市场中平衡力量分布，防止Docker在容器技术领域形成垄断地位，Google携手Red Hat、IBM等业界领军企业，共同创立了CNCF（Cloud Native Computing Foundation）基金会，即云原生计算基金会。这一举措体现了战略上的深远考量，旨在通过聚焦并推动云原生技术的发展，开辟新的技术战场。


CNCF的成立，其背后蕴含着明确的战略目标：既然在容器技术的直接应用领域难以与Docker直接抗衡，那么就将焦点转向Google更为擅长且拥有深厚积累的领域——大规模容器的编排与管理。为此，Google慷慨地将其内部高度成熟且广泛使用的Borg系统开源，这就是后来广为人知的Kubernetes，它成为了云原生技术生态中的核心组件，引领了云原生应用开发与部署的新潮流。


通过Kubernetes的开源与CNCF的推动，一个围绕云原生技术的生态系统逐渐繁荣起来，不仅为开发者提供了强大的容器编排工具，还促进了云原生应用架构、服务网格、持续集成/持续部署（CI/CD）等一系列相关技术的发展，共同塑造了现代云计算的新格局。


2016年，Docker公司雄心勃勃地推出了Docker Swarm，旨在整合Docker生态，构建一个集容器应用管理与大规模容器编排于一体的综合平台。然而，经过大约一年的市场实践与验证，Docker Swarm在容器编排领域的表现并未能撼动Kubernetes的稳固地位。面对这一现实，Docker公司于2017年做出了重大战略调整，正式宣布将原生支持Kubernetes纳入其技术架构之中，标志着Docker在大规模容器编排市场的直接竞争中暂时让出了领先地位。


尽管在容器编排战场上遭遇了挫折，但Docker并未因此放弃其作为PaaS平台（Platform as a Service）的愿景与追求。为了进一步巩固其市场地位并展示其开放合作的姿态，Docker随后将其核心组件Containerd捐赠给了CNCF（Cloud Native Computing Foundation），这一举动不仅体现了Docker对云原生技术生态的坚定支持，也重申了Docker作为PaaS平台，致力于提供全面、灵活且易于集成的容器化解决方案的承诺。通过这一系列举措，Docker在保持其技术创新力的同时，也为自己在云原生时代赢得了更广阔的发展空间。


2020年，CNCF基金会的一项重大宣布标志着Kubernetes技术生态的又一里程碑：Kubernetes 1.20版本将不再默认或专属支持Docker作为唯一的容器管理工具。这一变革的根源，深植于Docker向CNCF捐赠的Containerd项目中。起初，为了让Kubernetes能够兼容并充分利用Docker进行容器管理，开发者们在Kubernetes内部集成了shim技术，这一桥梁技术负责将Kubernetes的容器运行时接口（CRI）指令无缝转换为Docker的API调用，从而实现了两者之间的紧密协作。


然而，随着Kubernetes在全球技术市场的爆炸性增长与普及，越来越多的容器管理工具如雨后春笋般涌现，它们纷纷寻求与Kubernetes集成的机会，以扩大自身的用户基础和应用场景。这一趋势促使了对于标准化容器运行时接口的迫切需求，任何遵循该标准的工具都能轻松融入Kubernetes生态系统。因此，Kubernetes社区决定逐步减少对shim技术的依赖与维护，以推动更加开放和标准化的容器运行时环境。


与此同时，Containerd凭借其出色的性能、与Kubernetes的天然兼容性以及广泛的社区支持，迅速崛起为容器运行时领域的新星。Containerd不仅能够无缝对接Kubernetes，还提供了更为高效和稳定的容器管理能力，成为了众多企业和开发者首选的容器运行时解决方案。因此，随着Kubernetes 1.20版本的发布，Containerd正式接过了Kubernetes容器运行时主角的接力棒，引领着容器技术的新一轮发展浪潮。



概念

自2016年3月Docker 1.11版本起，Docker Engine内已初步集成了containerd，但随后的发展中，Docker公司做出了战略性的调整，将containerd从Docker Engine中完全分离出来，使之成为一个独立的开源项目，旨在构建一个更加开放、强健且稳定的容器运行时基础设施。


这一独立进程赋予了containerd更为丰富的功能集，使其能够全面覆盖容器运行时的各项管理需求，从镜像的传输、存储到容器的执行、监控，乃至底层存储与网络的优化，containerd均能提供强有力的支持。更为关键的是，独立后的containerd能够独立于Docker Engine进行特性更新与演进，从而更加专注于容器运行时的精细化管理，确保了系统的稳定与可靠。


Containerd作为工业标准的容器运行时解决方案，以其简洁、高效、跨平台（支持Linux与Windows）的特性而著称。它作为守护进程在主机上运行，全权负责镜像管理、容器生命周期控制等核心任务，同时通过兼容OCI（Open Container Initiative）标准的容器运行时（如runC）来实际执行容器操作，确保了技术的广泛兼容性与灵活性。


与Docker相比，containerd更加侧重于在大规模分布式系统（如Kubernetes、Swarm、Mesos等）中的集成与应用。在这些场景下，containerd+runC的组合以其轻量级、易于管理的特性，成为了容器编排服务的首选运行时环境。Containerd的设计初衷即是为了无缝融入这些复杂系统中，而非直接面向开发者或终端用户，这一特性使其在现代云原生架构中占据了举足轻重的地位。


特点

Containerd是一个基于gRPC构建的API与客户端库，其设计既简洁又高效，能够支持完整的OCI（Open Container Initiative）标准，涵盖运行时与镜像规范。其核心功能定义明确，旨在提供稳定且高性能的容器管理体验。Containerd采用了一种高度解耦的系统架构，使得镜像管理、文件系统操作与运行时环境能够各自独立，并支持通过插件机制进行灵活的扩展与重用。

Containerd承担以下关键职责：

  • 全生命周期管理：从容器的创建到销毁，Containerd全面掌控容器的生命周期，确保每个阶段都能高效、有序地进行

  • 镜像管理：支持镜像的拉取与推送操作，优化镜像的传输与存储效率，为容器应用提供坚实的镜像支持。

  • 存储优化：有效管理镜像与容器数据的存储，通过智能的存储策略提升数据访问速度与空间利用率。

  • 运行时交互：与符合OCI规范的容器运行时（如runC）紧密协作，负责调用并监控容器的实际执行过程。

  • 网络管理：配置并管理容器的网络接口与网络设置，确保容器间及容器与外部世界的顺畅通信。

在性能测试方面，利用bucketbench等工具对Docker、crio及Containerd进行对比分析，结果显示Containerd在启动、停止及删除容器等关键操作上均展现出卓越的性能优势，总体表现优于其他竞争对手，充分验证了其高效、稳定的容器管理能力


架构

Containerd 遵循经典的客户端-服务器（C/S）架构模式，其中服务端通过高效的gRPC协议对外暴露一套稳定的API接口，而客户端则通过这些API执行复杂的容器管理操作。为了实现高度的模块化和解耦，Containerd将系统内部划分为多个独立但又相互协作的组件，这些组件被称为子系统（subsystem），它们各自承担特定的职责。


Containerd的整体架构可以概括为三大核心部分：Storage（存储）、Metadata（元数据）和Runtime（运行时）。这三个部分共同构成了Containerd的基础框架，支撑起整个容器生命周期的管理。

进一步细分，Containerd包含两大关键子系统，它们分别是：

  • Bundle 子系统：在Containerd的语境中，Bundle是一个核心概念，它封装了容器运行所需的一切资源，包括配置文件、元数据信息以及根文件系统数据。简而言之，Bundle就是容器的文件系统环境。Bundle子系统的主要职责是从镜像中提取必要的文件和数据，并打包成Bundles，以供后续的运行时环境使用。

  • Runtime 子系统：与Bundle子系统紧密协作，Runtime子系统负责执Bundles，即创建并管理容器的运行实例。它通过调用底层的容器运行时（如runC）来实际启动容器，并监控其运行状态。Runtime子系统的行为同样由多个模块共同协作完成，这些模块共同构成了Containerd的核心部分，确保了容器的高效、稳定运行。

通过这种模块化和子系统的划分方式，Containerd实现了高度的灵活性和可扩展性，使得各个组件可以独立演进和升级，而不会影响到整个系统的稳定性和可用性。同时，这种设计也使得Containerd能够轻松集成到各种容器编排系统中，如Kubernetes等，为云原生应用的部署和管理提供了强有力的支持。


几个概念区分

Containerd，作为先进的容器管理器，扮演着守护进程的角色，专门负责在单机环境下全面管理容器的生命周期。从创建、启动到停止容器，再到镜像的拉取、存储、配置挂载及网络设置，containerd 一应俱全。它不仅是容器的核心控制中枢，也是容器技术栈中不可或缺的一环。


ctr 是专为 containerd 设计的一个命令行工具，虽然其界面设计与 Docker CLI 不兼容，且初看起来可能显得不那么直观，但它却是测试和优化 containerd 功能的强大伙伴。ctr 的主要用户群体是那些致力于容器技术开发的专家，他们通过 ctr 来深入探索 containerd 的内部机制和工作原理。


相比之下，nerdctl 是一个后来居上的 containerd 命令行客户端，它旨在提供更加用户友好的界面和与 Docker 相似的使用体验。通过 nerdctl，用户可以更加轻松地在 containerd 环境中执行容器管理任务，仿佛在使用 Docker 一样。因此，nerdctl + containerd 的组合被视为 Docker + dockerd 的一个现代、高效的替代品。


另一方面，crictl 是专为 Kubernetes 环境设计的命令行工具，它遵循 Kubernetes 容器运行时接口（CRI）标准。通过 CRI，Kubernetes 能够实现与底层容器运行时的解耦，从而支持多种不同的容器技术。kubelet 作为 Kubernetes 节点上的代理，通过实现 CRI 客户端 API，能够与任何遵循 CRI 服务器 API 的容器运行时进行交互，以管理节点上的容器和 Pod。这种设计使得 Kubernetes 能够灵活地适应不同的容器技术生态，同时也为用户提供了更多的选择和灵活性。


安装

containerd官网：

https://containerd.io/

containerd官方安装步骤：

https://github.com/containerd/containerd/blob/main/docs/getting-started.md

下载好相应的安装部署包【所有安装包都可在github上进行下载】如下：

[root@n1 data]# ll contianerd/total 104224-rw-r--r--. 1 root root 48222725 Jul 30 11:27 cni-plugins-linux-amd64-v1.5.1.tgz-rw-r--r--. 1 root root 47716668 Mar 11 23:23 containerd-1.7.14-linux-amd64.tar.gz-rw-r--r--. 1 root root 10779104 Jul 30 10:31 runc.amd64[root@n1 data]# 
[root@n1 contianerd]# tar Cxzvf /usr/local/ containerd-1.7.14-linux-amd64.tar.gz bin/bin/containerd-shimbin/ctrbin/containerd-shim-runc-v1bin/containerdbin/containerd-stressbin/containerd-shim-runc-v2


将containerd服务设置卫开机启动，先配置为系统服务


源文件：

https://raw.githubusercontent.com/containerd/containerd/main/containerd.servicevim /etc/systemd/system/containerd.service
# Copyright The containerd Authors.## Licensed under the Apache License, Version 2.0 (the "License");# you may not use this file except in compliance with the License.# You may obtain a copy of the License at##     http://www.apache.org/licenses/LICENSE-2.0## Unless required by applicable law or agreed to in writing, software# distributed under the License is distributed on an "AS IS" BASIS,# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.# See the License for the specific language governing permissions and# limitations under the License.
[Unit]Description=containerd container runtimeDocumentation=https://containerd.ioAfter=network.target local-fs.target
[Service]ExecStartPre=-/sbin/modprobe overlayExecStart=/usr/local/bin/containerd
Type=notifyDelegate=yesKillMode=processRestart=alwaysRestartSec=5
# Having non-zero Limit*s causes performance problems due to accounting overhead# in the kernel. We recommend using cgroups to do container-local accounting.LimitNPROC=infinityLimitCORE=infinity
# Comment TasksMax if your systemd version does not supports it.# Only systemd 226 and above support this version.TasksMax=infinityOOMScoreAdjust=-999
[Install]WantedBy=multi-user.target


将containerd服务设置卫开机启动

[root@n1 contianerd]# systemctl daemon-reload[root@n1 contianerd]# systemctl enable --now containerdCreated symlink from /etc/systemd/system/multi-user.target.wants/containerd.service to /etc/systemd/system/containerd.service.[root@n1 contianerd]#


验证

[root@n1 contianerd]# ctr versionClient:  Version:  v1.7.14  Revision: dcf2847247e18caba8dce86522029642f60fe96b  Go version: go1.21.8
Server:  Version:  v1.7.14  Revision: dcf2847247e18caba8dce86522029642f60fe96b  UUID: ea44187c-e4da-467d-85a6-6606cc8d8986[root@n1 contianerd]#


至此，containerd安装完成

runc安装

https://github.com/opencontainers/runc/releases

[root@n1 contianerd]# wget https://github.com/opencontainers/runc/releases/download/v1.2.0-rc.1/runc.amd64[root@n1 contianerd]# install -m 755 runc.amd64 /usr/local/sbin/runc[root@n1 contianerd]#

验证

[root@n1 contianerd]# runc -vrunc version 1.2.0-rc.1commit: v1.2.0-rc.1-0-g275e6d85spec: 1.2.0go: go1.20.14libseccomp: 2.5.5[root@n1 contianerd]#


安装CNI插件

https://github.com/containernetworking/plugins/releases
wget https://github.com/containernetworking/plugins/releases/download/v1.5.1/cni-plugins-linux-amd64-v1.5.1.tgz[root@n1 contianerd]# tar Cxzvf /opt/cni/bin cni-plugins-linux-amd64-v1.5.1.tgz ././dhcp./loopback./README.md./bandwidth./ipvlan./vlan./static./host-device./LICENSE./bridge./dummy./tuning./vrf./tap./portmap./firewall./ptp./host-local./macvlan./sbr[root@n1 contianerd]#


ctr命令操作

ctr是作为 containerd 项目的一部分提供的命令行客户端。

该ctr界面 [显然] 与 Docker CLI不兼容，乍一看，可能看起来不太用户友好。显然，它的主要受众是测试守护进程的容器开发人员。但是，由于它最接近实际的 containerd API，因此它可以作为一种很好的探索手段——通过检查可用命令，可以大致了解 containerd可以做什么和不可以做什么。

[root@n1 contianerd]# ctr --help NAME:   ctr -         __  _____/ /______ / ___/ __/ ___// /__/ /_/ /\___/\__/_/
containerd CLI

USAGE:   ctr [global options] command [command options] [arguments...]
VERSION:   v1.7.14
DESCRIPTION:   ctr is an unsupported debug and administrative client for interactingwith the containerd daemon. Because it is unsupported, the commands,options, and operations are not guaranteed to be backward compatible orstable from release to release of the containerd project.
COMMANDS:   plugins, plugin            Provides information about containerd plugins   version                    Print the client and server versions   containers, c, container   Manage containers   content                    Manage content   events, event              Display containerd events   images, image, i           Manage images   leases                     Manage leases   namespaces, namespace, ns  Manage namespaces   pprof                      Provide golang pprof outputs for containerd   run                        Run a container   snapshots, snapshot        Manage snapshots   tasks, t, task             Manage tasks   install                    Install a new package   oci                        OCI tools   sandboxes, sandbox, sb, s  Manage sandboxes   info                       Print the server info   deprecations                  shim                       Interact with a shim directly   help, h                    Shows a list of commands or help for one command
GLOBAL OPTIONS:   --debug                      Enable debug output in logs   --address value, -a value    Address for containerd's GRPC server (default: "/run/containerd/containerd.sock") [$CONTAINERD_ADDRESS]   --timeout value              Total timeout for ctr commands (default: 0s)   --connect-timeout value      Timeout for connecting to containerd (default: 0s)   --namespace value, -n value  Namespace to use with commands (default: "default") [$CONTAINERD_NAMESPACE]   --help, -h                   show help   --version, -v                print the version[root@n1 contianerd]#


container镜像管理

# 拉取镜像  拉取镜像，完全合格的参考似乎是必需的，所以不能忽略镜像仓库或标签部分。$ ctr images pull --all-platforms docker.io/library/nginx:alpine# --all-platforms  指定所有平台镜像  # --platform       指定系统平台$ ctr images pull --platform linux/amd64 docker.io/library/nginx:latest
# 查看镜像$ ctr images ls
# 挂载镜像$ ctr images mount docker.io/library/nginx:alpine /mnt$ ls /mnt$ umount /mnt
# 镜像导出，并保存为nginx.img文件$ ctr i export --all-platforms nginx.img docker.io/library/nginx:alpine$ ls -l-rw-r--r-- 1 root root 70138368 Sep  2 16:33 nginx.img
# 镜像导入$ ctr images import nginx.img
# 镜像打tag$ ctr images tag docker.io/library/nginx:alpine nginx:alpine
# 镜像对比$ ctr images check


容器管理

# 创建【静态】容器# 该命令创建容器后，容器并没有处于运行状态，其只是一个静态的容器。这个container对象只是包含了运行一个容器所需的资源及配置的数据结构，例如： namespaces、rootfs 和容器的配置都已经初始化成功了，只是用户进程(本案例为nginx)还没有启动。需要使用`ctr tasks`命令才能获取一个动态容器。$ ctr container create docker.io/library/nginx:alpine testnginx1
# 启动【动态】容器  创建容器和任务子命令分离$ ctr task start -d testnginx1
# 直接运行一个动态容器【容器的IP就是宿主机的IP】# ctr运行命令实际上是ctr容器创建+ ctr任务启动的快捷方式$ ctr run -d --net-host docker.io/library/nginx:alpine testnginx2
# 查看【静态】容器$ ctr container ls
# 查看【动态】容器$ ctr task ps testnginx1PID      INFO64574    -64613    -64614    -64615    -64616    -# 物理机上查看$ ps -ef | grep nginxroot      64574  64553  0 16:41 ?        00:00:00 nginx: master process nginx -g daemon off;101       64613  64574  0 16:41 ?        00:00:00 nginx: worker process101       64614  64574  0 16:41 ?        00:00:00 nginx: worker process101       64615  64574  0 16:41 ?        00:00:00 nginx: worker process101       64616  64574  0 16:41 ?        00:00:00 nginx: worker process
# 进入容器$ ctr task exec --exec-id 1 testnginx2 sh# 查看网卡ifconfig  ens33     Link encap:Ethernet  HWaddr 00:0C:29:32:CC:B0            inet addr:192.168.168.201  Bcast:192.168.168.255  Mask:255.255.255.0          inet6 addr: fe80::63d5:da66:d3db:fa1c/64 Scope:Link          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          RX packets:476940 errors:0 dropped:0 overruns:0 frame:0          TX packets:595381 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000           RX bytes:175687016 (167.5 MiB)  TX bytes:149770479 (142.8 MiB)lo        Link encap:Local Loopback            inet addr:127.0.0.1  Mask:255.0.0.0          inet6 addr: ::1/128 Scope:Host          UP LOOPBACK RUNNING  MTU:65536  Metric:1          RX packets:0 errors:0 dropped:0 overruns:0 frame:0          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0          collisions:0 txqueuelen:1000           RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)# 为容器中运行的网站添加网站文件echo "hello nginx2" > /usr/share/nginx/html/index.html# 在容器里访问curl 127.0.0.1# 退出容器          exit
# 在宿主机上访问$ curl 192.168.168.201hello nginx2
# 暂停容器$ ctr task pause testnginx2
# 恢复容器$ ctr task resume testnginx2
# 停止容器$ ctr task kill testnginx2
# 删除动态容器【必须先停止】$ ctr task delete testnginx2
# 删除静态容器$ ctr container delete testnginx2


命名空间管理

containerd中namespace的作用为：隔离运行的容器，可以实现运行多个容器。

# 拉取镜像$ ctr namespace --help
# 创建命名空间$ ctr ns create testns
# 查看命名空间$ ctr ns ls
# 在命名空间中进行镜像、容器等相关操作$ ctr -n testns images pull docker.io/library/nginx:latest$ ctr -n testns images ls$ ctr -n testns container create docker.io/library/nginx:latest$ ctr -n testns container ls
# 删除命名空间$ ctr ns rm testns




网络管理

默认Containerd管理的容器仅有lo网络，无法访问容器之外的网络，可以为其添加网络插件，使用容器可以连接外网，CNI（Container Network Interface）

# cni插件目录$ cd /home/cni-plugins# cni工具包目录$ cd /home/cni-tools/cni-1.1.2# cni工具1.1.2兼容cni插件1.0.0


准备容器网络配置文件，用于为容器提供网关、IP地址等。

$ vim /etc/cni/net.d/10-mynet.conf$ vim /etc/cni/net.d/99-loopback.conf$ cat /etc/cni/net.d/10-mynet.conf{    "cniVersion": "1.0.0",    "name": "mynet",    "type": "bridge",    "bridge": "cni0",    "isGateway": true,    "ipMasq": true,    "ipam": {        "type": "host-local",        "subnet": "10.66.0.0/16",        "routes": [            {                "dst": "0.0.0.0/0"            }        ]    }}$ cat /etc/cni/net.d/99-loopback.conf{    "cniVerion": "1.0.0",    "name": "lo",    "type": "loopback"}


生成cni网络

# 获取epel源$ wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo
#安装jq【jq是一个'出色'的'针对-->JSON处理器'的命令行】$ yum -y install jq
# 进入cni工具目录$ cd /home/cni-tools/cni-1.1.2
# 执行脚本文件，基于/etc/cni/net.d/目录中的*.conf配置文件生成容器网络# CNI_PATH是cni插件安装的目录$ CNI_PATH=/home/cni-plugins ./priv-net-run.sh echo "Hello World"# cni插件和cni工具包版本要兼容，否则可能会报错如下：mynet : error executing ADD: {    "code": 1,    "msg": "incompatible CNI versions",    "details": "config is \"1.0.0\", plugin supports [\"0.1.0\" \"0.2.0\" \"0.3.0\" \"0.3.1\" \"0.4.0\"]"}
#安装成功后，在宿主机上查看是否生成容器网络名为cni0的网桥$ ip a s1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00    inet 127.0.0.1/8 scope host lo       valid_lft forever preferred_lft forever    inet6 ::1/128 scope host        valid_lft forever preferred_lft forever...7: cni0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000    link/ether 6a:32:bc:eb:0f:23 brd ff:ff:ff:ff:ff:ff    inet 10.66.0.1/16 brd 10.66.255.255 scope global cni0       valid_lft forever preferred_lft forever    inet6 fe80::6832:bcff:feeb:f23/64 scope link        valid_lft forever preferred_lft forever


创建容器

$ ctr images pull docker.io/library/busybox:latest$ ctr run -d docker.io/library/busybox:latest busybox$ ctr tasks exec --exec-id $RANDOM -t busybox sh/ # ip a s1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00    inet 127.0.0.1/8 scope host lo       valid_lft forever preferred_lft forever    inet6 ::1/128 scope host        valid_lft forever preferred_lft forever2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000    link/ipip 0.0.0.0 brd 0.0.0.0
#获取容器进程ID及其网络命名空间$ pid=$(ctr tasks ls | grep busybox | awk '{print $2}') && echo $pid39287$ netnspath=/proc/$pid/ns/net && echo $netnspath/proc/39287/ns/net
# 进入目录为指定容器添加网络配置$ cd /home/cni-tools/cni-1.1.2/scripts/$ CNI_PATH=/home/cni-plugins ./exec-plugins.sh add $pid $netnspath


验证容器网络与宿主机网络的互访功能

# 验证# 进入容器确认是否添加网卡信息$ ctr tasks exec --exec-id $RANDOM -t busybox sh/ # ip a s1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00    inet 127.0.0.1/8 scope host lo       valid_lft forever preferred_lft forever    inet6 ::1/128 scope host        valid_lft forever preferred_lft forever2: tunl0@NONE: <NOARP> mtu 1480 qdisc noop qlen 1000    link/ipip 0.0.0.0 brd 0.0.0.03: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue     link/ether 5a:36:90:c1:33:b1 brd ff:ff:ff:ff:ff:ff    inet 10.66.0.4/16 brd 10.66.255.255 scope global eth0       valid_lft forever preferred_lft forever    inet6 fe80::5836:90ff:fec1:33b1/64 scope link        valid_lft forever preferred_lft forever# 在容器中ping容器宿主机IP地址/ # ping -c 2 192.168.168.201PING 192.168.168.201 (192.168.168.201): 56 data bytes64 bytes from 192.168.168.201: seq=0 ttl=64 time=0.067 ms64 bytes from 192.168.168.201: seq=1 ttl=64 time=0.070 ms
--- 192.168.168.201 ping statistics ---2 packets transmitted, 2 packets received, 0% packet lossround-trip min/avg/max = 0.067/0.068/0.070 ms
# 在容器中ping容器宿主机IP地址/ # ping -c 2 192.168.168.2PING 192.168.168.2 (192.168.168.2): 56 data bytes64 bytes from 192.168.168.2: seq=0 ttl=127 time=0.141 ms64 bytes from 192.168.168.2: seq=1 ttl=127 time=0.324 ms
--- 192.168.168.2 ping statistics ---2 packets transmitted, 2 packets received, 0% packet lossround-trip min/avg/max = 0.141/0.232/0.324 ms
# 在容器中ping容器宿主机IP地址/ # ping -c 2 192.168.168.202PING 192.168.168.201 (192.168.168.202): 56 data bytes64 bytes from 192.168.168.202: seq=0 ttl=64 time=0.067 ms64 bytes from 192.168.168.202: seq=1 ttl=64 time=0.070 ms
--- 192.168.168.202 ping statistics ---2 packets transmitted, 2 packets received, 0% packet lossround-trip min/avg/max = 0.067/0.068/0.070 ms
# 在容器中开启httpd服务/ # echo "containerd net web test" > /tmp/index.html/ # httpd -h /tmp/ # wget -O - -q 127.0.0.1containerd net web test/ # exit
#在宿主机访问容器提供的httpd服务$ curl 10.66.0.4containerd net web test


数据持久化

实现把宿主机目录挂载至Containerd容器中，实现容器数据持久化存储

# 创建一个静态容器，实现宿主机目录与容器挂载，src=/tmp 为宿主机目录 dst=/hostdir 为容器中目录$ ctr container create docker.io/library/busybox:latest busybox3 --mount type=bind,src=/tmp,dst=/hostdir,options=rbind:rw
# 运行用户进程$ ctr tasks start -d busybox3 bash$ ctr t lsTASK        PID       STATUS    busybox     39287     RUNNINGbusybox3    105003    RUNNING
# 进入容器，查看是否挂载成功$ ctr tasks exec --exec-id $RANDOM -t busybox3 sh/ # ls /hostdir/ks-script-GSRMK8                                                         vmware-root_6389-1958486695systemd-private-cc74dd8802f0428490924757e690c750-chronyd.service-9TDICh  vmware-root_6511-1689719547vmware-root_6359-1949639453                                              yum.log# 向容器中挂载目录中添加文件/ # echo "hello world" > /hostdir/test.txt/ # ls /hostdir/ks-script-GSRMK8                                                         vmware-root_6389-1958486695systemd-private-cc74dd8802f0428490924757e690c750-chronyd.service-9TDICh  vmware-root_6511-1689719547test.txt                                                                 yum.logvmware-root_6359-1949639453# 在宿主机上查看被容器挂载的目录中是否添加了新的文件，已添加表明被容器挂载成功，并可以读写此目录中内容。$ cat /tmp/test.txt hello world



Docker集成Container容器管理

目前Containerd主要任务还在于解决容器运行时的问题，对于其周边生态还不完善，所以有时需要借助：Docker结合Containerd来实现Docker完整的功能应用。docker运行的容器默认在moby命名空间下。

# 安装docker$ yum install docker# 启动docker$ systemctl start docker
# 运行一个容器$ docker run -d nginx:latest$ docker ps
# 查看ctr命令下的namespace，发现多了一个moby命名空间。moby即为docker使用的命名空间。$ ctr namespace lsNAME    LABELS default        k8s.io         moby
# 查看moby命名空间下的容器和任务$ ctr -n moby container ls$ ctr -n moby tasks ls




THE

END

期待你的

分享

点赞

在看

添加博主

微信号｜yfq940-



原文作者：步步运维步步坑；如有侵权，请联系管理员删除。

0
0
上一篇： 高级运维必看的操作系统内存管理解析
下一篇： Service Mesh从0-1教程（下）
请登录后发表评论 登录
全部评论
步步运维步步坑

注册时间：2022-10-08

  • 博文量
    100
  • 访问量
    51732

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593