
📅 2021-06-13
通过上节内容的学习,nerdctl在启动容器时连接的网络默认是bridge,除此之外还可以使用--net
选项指定其他网络模式。
1--network value, --net value Connect a container to a network ("bridge"|"host"|"none") (default: "bridge")
从nerdctl命令的帮助中给出了使用--net
选项指定启动容器时连接的网络,默认是brdige
,另外还可以选择none
和host
。
因为容器连接的网络是由CNI插件实现的,所以除了bridge
, host
, none
这3个选项外,还可以指定手动添加的CNI配置。
下面分别看一下这几种不同的网络。
...📅 2021-06-12
从本节开始学习容器网络,根据前面已经学习过的内容,单机模式下使用容器的最佳组合是nerdctl+containerd+buildkit,这套组合已经可以在本地开发、测试和单机容器部署方面替代docker了。关于容器网络的学习,就先从nerdctl启动容器的创建的brdige网络开始吧。
...📅 2021-06-11
前面已经完成了rootless模式下buildkitd的二进制部署,本节将buildkitd部署到k8s集群中。
具体的环境信息k8s集群版本1.20.7,服务器系统CentOS 7.9,Jenkins Master通过使用kubernetes-plugin使运行job的jenkins slave(pod)在k8s集群上的jenkins namespace内动态创建。
...📅 2021-06-10
本节做一个实战的练习,使用buildkit完成容器镜像的远程构建,即实现本地的buildctl客户端远程请求服务器上的buildkitd完成一个容器镜像的构建并推送到镜像仓库中。
部署buildkitd服务端, 暴露为TCP服务
#
下面将在服务器上以二进制的形式部署服务端buildkitd,并将其gRPC API以TCP服务的形式暴露出来。
此处在部署buildkitd的时候是以具备生产环境可用为目的,为了安全性会以rootless的形式启动buildkitd,同时为gRPC Server和Client生成TLS证书,开启TLS认证以保障服务的安全。
...📅 2021-06-09
本节一起看一下都有哪些可用于构建容器镜像的工具和方案。可能你会疑问,构建镜像不就是使用docker build
就可以吗,即使将来docker真的退出历史舞台,不还有containerd吗,前面第5节的时候也介绍了在containerd下可以使用nerdctl+buildkit构建容器镜像。
如果你只是在单机本地构建镜像的话,使用docker build
或nerdctl+containerd+buildkit
确实没有问题,但实际中由于不同场景和技术背景下的限制,如docker build
依赖于docker daemon
,这些限制使得在一些特殊的场景下本机构建镜像的方式不再可用。
...📅 2021-06-03
前面学习了容器运行时containerd的基本使用,containerd的架构,namespace, cgroup, rootfs等容器背后的技术。
本节做一个阶段性的小节。此时,如果有人问"容器是什么?",我们可能会给出以下的回答:
- 容器实际上是一种特殊的进程。它使用namespace进行隔离,使用cgroup进行资源限制,并且它还以联合文件系统的形式挂载了单独的rootfs。
- 为了更方便的准备运行容器所需的资源和管理容器的生命周期,还需要容器引擎如containerd。
- 容器镜像实际上就是一种特殊的文件系统,它包含容器运行所需的程序、库、资源配置等所有内容,构建后内容保持不变。在启动容器时镜像会挂载为容器的rootfs。
既然容器仅仅是一种特殊的进程,下面我们实际去探索一下它的存在。继续前面启动的redis容器为例,可以使用nerdctl inspect <container id>
和ctr c info <container id>
查看一下容器的信息。
下面的命令可以打印出容器在宿主机上的进程id:
...📅 2021-06-02
前面我们简单理解了Containerd的架构,本节来看一下Containerd是如何存储镜像和容器的,涉及到内容包括如何镜像存储和RootFS。
从pull镜像到启动容器
#
Containerd的配置文件中有如下两项配置:
1root = /var/lib/containerd
2state = "/run/containerd"
root配置的目录是用来保存持久化数据的目录,包括content
, snapshot
, metadata
和runtime
。
下面在一台测试的服务器上,删除所有的镜像和容器后,再执行下面的命令重新初始化一下这些目录,以准备后边的实验。
...📅 2021-06-01
最近跨网段配置k8s calico网络遇到了问题,简短记录一下解决过程。
测试环境本地的物理服务器上有一个k8s集群,版本是1.20,calico网络组件版本为3.17。
现在需要往这个k8s集群中添加2个新的node节点,新的节点在本地Openstack的虚拟机上。
Openstack虚拟机的网络和测试环境物理服务器之间网络已经打通,但属于不同的网段,
已在Openstack中安全组中配置了允许物理机服务器网段所有TCP协议进入。
...📅 2021-05-24
起因
#
近日使用团队内部一直在维护的ansible role playbook初始化一个新的k8s集群(v1.19)时遇到了问题,kubectl get node
命令显示各个节点一直是NotReady状态,同时各节点上的kubelet日志一直报下面的错误:
1... kubelet.go:2209] node "node1" not found
2... reflector.go:127] k8s.io/client-go/informers/factory.go:134: Failed to watch *v1.Node: failed to list *v1.Node: nodes "node1" is forbidden: User "system:node:node1" cannot list resource "nodes" in API group "" at the cluster scope
3... failed to ensure node lease exists, will retry in 7s, error: leases.coordination.k8s.io "node1" is forbidden: User "system:node:node1" cannot get resource "leases" in API group "coordination.k8s.io" in...mespace "kube-node-lease"
4... kubelet_node_status.go:470] Error updating node status, will retry: error getting node "node1": nodes "node1" is forbidden: User "system:node:node1" cannot get resource "nodes" in API group "" at the cluster scope
从日志中初步分析是kubelet对apiserver的访问权限问题引起,由于使用这个ansible role是团队内部一直在维护的,目前管理着线上线下共4套k8s集群,一直没有这个问题出现。于是初步怀疑已有的4套集群是经历了各个历史版本逐步升级到1.19的,这个过程中可能k8s给自动做了相关的配置兼容性,
现在初始化的这个新集群因为是全新安装,可能我们的ansible playbook生成的配置已经不正确了。
...📅 2021-05-23
前面我们从实际操作角度学习了containerd,部署了containerd,并学习使用了ctr, crictl, nerdctl等命令行工具,体验了容器镜像的构建、拉取、推送,容器的启动和管理,并结合containerd容器学习了容器隔离性和资源限制背后的技术namespace和cgroups。在积累了这些实际操作的经验之后,本节一起来从概念角度学习一下Containerd的架构,进一步加深理解。本节学习内容主要来自Containerd的官方文档Containerd Architecture。
...