导语：下载镜像到最后会提示unknown method AddResource: not implemented
|
1 2 3 4 5 6 |
<span class="pipeline-node-17">+ docker buildx build --output=type=local,name=openeuler,dest=./resources --platform=linux/amd64,linux/arm64 -f build/Dockerfile.os.openeuler . #1 [internal] booting buildkit #1 pulling image moby/buildkit:buildx-stable-1 #1 pulling image moby/buildkit:buildx-stable-1 11.0s done #1 creating container buildx_buildkit_multi-platform0 0.0s done #1 ERROR: Error response from daemon: No such image: moby/buildkit:buildx-stable-1</span> |
原因， 安装完docker启动后， 还需要重启一下containerd服务
sudo systemctl restart containerd.service
sudo systemctl restart docker
参考https://blog.csdn.net/sinat_14840559/article/details/114399166
前言 使用本地磁盘作为pv kubernetes从1.10版本开始支持local volume（本地卷），workload（不仅是statefulsets类型）可以充分利用本地磁盘的优势，从而获取比remote volume（如nas, nfs, cephfs、RBD）更好的性能。 在local volume出现之前，statefulsets也可以利用本地磁盘，方法是配置hostPath，并通过nodeSelector或者nodeAffinity绑定到具体node上。但hostPath的问题是，管理员需要手动管理集群各个node的目录，不太方便。 以上无论是hostPath还是local volume都不支持动态扩容，并且程序移植改动比较大。 由于项目的需要，需要支持动态创建和扩容pv/pvc 本文参考了以下两个开源项目： https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner https://github.com/rancher/local-path-provisioner 经过测试： kubernetes-sigs版不支持动态扩容/动态供给dynamically provisioning，而且需要提前手动在node节点上创建并且mount对应的挂载点。 Rancher版本的local-path-provisioner支持动态创建挂载点，动态创建pv 下面两种方法都介绍一下安全和使用方式，最后推荐使用第三章介绍的local-path-provisioner来进行动态创建pv 第一章 使用sig-storage-local-static-provisioner 1.1 拉取官方源码进行安装 [crayon-67f3038ac4f80329699281/] 1.2创建storageclass [crayon-67f3038ac4f83417418422/] 1.3挂载磁盘 其Provisioner本身其并不提供local volume，但它在各个节点上的provisioner会去动态的“发现”挂载点（discovery directory），当某node的provisioner在/mnt/fast-disks目录下发现有挂载点时，会创建PV，该PV的local.path就是挂载点，并设置nodeAffinity为该node。 可以用以下脚本通过mount bind方式创建和挂载磁盘 [crayon-67f3038ac4f84974142703/] 下面是在各个node节点用以上脚本创建挂载点： Read more…
Kubectl 是 Kubernetes 最重要的命令行工具。在 Flant，我们会在 Wiki 和 Slack 上相互分享 Kubectl 的妙用（其实我们还有个搜索引擎，不过那就是另外一回事了）。多年以来，我们在 kubectl 方面积累了很多技巧，现在想要将其中的部分分享给社区。 我相信很多读者对这些命令都非常熟悉；然而我还是希望读者能够从本文中有所获益，进而提高生产力。 下列内容有的是来自我们的工程师，还有的是来自互联网。我们对后者也进行了测试，并且确认其有效性。 现在开始吧。 获取 Pod 和节点 我猜你知道如何获取 Kubernetes 集群中所有 Namespace 的 Pod——使用 --all-namepsaces 就可以。然而不少朋友还不知道，现在这一开关还有了 -A 的缩写。 如何查找非 running 状态的 Pod 呢？ kubectl Read more…
最新在信创项目中，经常需要构建支持amd64和arm64架构的镜像，而有的场景在同一个 Kubernetes 集群中的节点是混合架构的，也就是说，其中某些节点的 CPU 架构是 x86 的，而另一些节点是 ARM 的。为了让我们的镜像在这样的环境下运行，一种最简单的做法是根据节点类型为其打上相应的标签，然后针对不同的架构构建不同的镜像，比如 demo:v1-amd64 和 demo:v1-arm64，然后还需要写两套 YAML：一套使用 demo:v1-amd64 镜像，并通过 nodeSelector 选择 x86 的节点，另一套使用 demo:v1-arm64 镜像，并通过 nodeSelector 选择 ARM 的节点。很显然，这种做法不仅非常繁琐，而且管理起来也相当麻烦，如果集群中还有其他架构的节点，那么维护成本将成倍增加。 你可能知道，每个 Docker 镜像都是通过一个 manifest 来描述的，manifest 中包含了这个镜像的基本信息，包括它的 mediaType、大小、摘要以及每一层的分层信息等。可以使用 docker manifest inspect 查看某个镜像的 manifest 信息： [crayon-67f3038ac6482201099165/] 可以加上 --verbose 查看更详细的信息，包括该 manifest 引用的镜像标签和架构信息： [crayon-67f3038ac6486956518016/] 我们一般不会直接使用 manifest，而是通过标签来关联它，方便人们使用。从上面的输出结果可以看出，该 manifest 通过 docker.io/aneasystone/hello-actuator:v1 这个镜像标签来关联，支持的平台是 linux/amd64，该镜像有四个分层，另外注意这里的 mediaType 字段，它的值是 application/vnd.docker.distribution.manifest.v2+json，表示这是 Docker Read more…
0 Comments