Tip：

netdata、 docker login、docker pull/push，crictl pull，ctr -n=k8s.io i pull/push、--all-platforms、containerd、 blobs（Binary Large Object，二进制大对象）、Version header、insecure registry 、CRI plugin

！！！请注意，/etc/containerd/config.toml中[plugins."io.containerd.grpc.v1.cri"] 部分是专门针对 CRI 的，其他诸如 ctr、nerdctl 以及 Docker/Moby 等 containerd 客户端无法识别此部分。——>containerd是通过cri plugin使用 image registry。

——> 在 containerd v1.5 中，已为 ctr 客户端（供admins/developers使用的 containerd 工具）、containerd 镜像服务客户端以及诸如 kubectl 和 crictl 之类的 CRI 客户端实现了新的和额外的 registry hosts config (hosts.toml配置registries)支持。

1、厌倦了设置和维护Prometheus&Grafana？立即尝试Netdata！通过高分辨率指标、日志记录和实时可视化感受您的基础设施的脉搏。具有全自动仪表板和数百个预配置警报。Netdata增强了您的可观察性技能，加速了您的故障排除，同时保持事情简单易行。通过基于团队的intelligence-assisted故障排除，缩短解决时间。

  • 在Learn Netdata，可以找到用于使用Netdata监控和排除系统故障的留档和参考资料。使用每秒指标、富有洞察力的可视化和所有可以想象的指标，发现有关系统、容器和应用程序的新见解。netdata configuration的生成：：netdatacli dumpconfig > /etc/netdata/netdata.conf
# 安装依赖       
yum install -y autoconf automake curl gcc git libmnl-devel libuuid-devel lm_sensors make MySQL-python nc pkgconfig python python-psycopg2 PyYAML zlib-devel        
# 拉取git仓库
git clone https://github.com/netdata/netdata.git --depth=1       
# 执行安装脚本        
./netdata-installer.sh
---
***：实际应用中，直接执行以下脚本完成安装，且不需要改配置文件，直接可以访问http://192.168.31.211:19999/
sh ./netdata-kickstart.sh   （wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh）
systemctl enable --now netdata
---
download netdata configuration using:
#  wget -O /etc/netdata/netdata.conf http://localhost:19999/netdata.conf
#  curl -o /etc/netdata/netdata.conf http://localhost:19999/netdata.conf
vim netdata.conf 
  listen_ip = 0.0.0.0
systemctl restart netdata
  • 具有全自动仪表板和数百个预配置警报。Netdata增强了您的可观察性技能，加速了您的故障排除，同时保持事情简单易行。快速、实时、高保真和低延迟立即获得可操作的见解，揭示系统和应用程序的微观行为。
  • Unsupervised Anomaly异常 Detection：Trains multiple Machine-Learning (ML) models for each metric and uses AI to detect anomalies based on the past behavior of each metric.
  • 释放实时、全面和智能警报的力量。通过覆盖系统各个方面的数十个预配置警报，以及完全自动化的操作，您不仅可以解决问题，还可以领先一步。通过AI驱动的异常检测增强您的监控能力，该检测完全自动化、无监督且在边缘运行。
  • 使用Netdata和Systemd Journal有效且集中地探索系统日志。体验可靠、高效、安全且具有成本效益的日志管理解决方案。
  • 监控应该简单（且有趣）：Netdata不需要您深入了解每个指标是什么，也不需要您花费大量时间来配置监控，而是为每个指标收集、存储、查询、可视化、警报甚至训练机器学习模型！因此，当您探索基础架构和应用程序时，或者当您解决问题时，您就能够理解指标。

1.1、监控示例：http://agent-ip:19999

k8s笔记18（netdata/GitHub Actions/pull-push aliyuncs）_基础设施

2、向aliyun推送镜像。在终端中输入访问凭证，登录Registry实例，这里选择之前创建的命名空间：mizy

//同一个账号可以将镜像Push到不同的区域如cn-hangzhou、us-west-1（美国硅谷）或cn-beijing等，在阿里云容器镜像服务-个人实例一栏登录Registry实例中有名称示例
docker login --username=账号 registry.cn-hangzhou.aliyuncs.com   //registry.cn-<个人版实例所在的地域>.aliyuncs.com
docker tag core.harbor.domain/mizy/nginx:1.7.9  registry.cn-hangzhou.aliyuncs.com/mizy/nginx:1.7.9 
docker push registry.cn-hangzhou.aliyuncs.com/mizy/nginx:1.7.9

3、 GitHub Actions工具将 DockerHub 上的镜像同步到阿里云容器镜像服务。阿里云容器镜像服务提供了个人实例服务，支持最多创建300个仓库，而且免费。个人使用完全够满足需求。

  • Github 有个 Actions 平台，是利用在国外的主机来执行开发者创建任务，这次，利用这个平台，来向阿里云容器镜像服务同步 Docker 仓库。
  • GitHub Actions 可以当成一种免费的云服务器， 是 GitHub 提供的一项持续集成和持续交付（CI/CD）服务。允许开发者在代码库中自动化各种任务，例如构建、测试和部署代码。通过定义工作流（workflow），开发者可以在特定事件（如代码推送、拉取请求等）发生时自动触发这些任务。所以可以自动进行构建和完成镜像的推送，并且是同时把镜像推送到DockerHub 和 阿里云的 Docker 镜像中。
  • 将https://github.com/ikrong/sync-docker-image仓库fork一份，配置阿里云容器镜像服务账号和密码， Name 必须为 DESTINATION_CREDENTIAL 且内容格式必须为:  Username:Password 即用户名和密码并且用冒号分隔。就可以通过 Github Actions 的界面填写表单开始启动同步。
  • copy.yml 主要是将 DockerHub 上某个仓库下的某个标签同步到阿里云容器镜像仓库。
  • sync.yml 主要是将 DockerHub 上某个仓库下的所有标签全部同步到阿里云镜像仓库。

k8s笔记18（netdata/GitHub Actions/pull-push aliyuncs）_.net_02

  • 当使用上面办法将镜像同步到阿里云镜像仓库后，就可以直接使用阿里云镜像仓库的镜像了。
  • docker pull/push均ok，crictl pull（没有push功能）OK，ctr -n=k8s.io i pull/push均OK。
docker pull registry.cn-beijing.aliyuncs.com/atc-airnet/alpine
docker push registry.cn-beijing.aliyuncs.com/mizy/qanything-win:v1.2.2 //或如上workflow这个35.4GB大小的镜像也没问题
 crictl pull registry.cn-beijing.aliyuncs.com/atc-airnet/alpine   //ok！atc-airnet是公开镜像仓库，有时需多执行几次
 crictl pull --creds sxzdsbs:pw  registry.cn-beijing.aliyuncs.com/mizy/nginx:1.13  //ok！ mizy是私有镜像仓库，authorization failed需加--creds
ctr -n=k8s.io images pull registry.cn-beijing.aliyuncs.com/atc-airnet/alpine:latest  //ok！atc-airnet是公开镜像仓库
ctr -n=k8s.io i pull -u sxzdsbs:pw registry.cn-beijing.aliyuncs.com/mizy/nginx:1.13  //ok！ mizy是私有镜像仓库,需加-u
ctr -n=k8s.io i push   registry.cn-beijing.aliyuncs.com/atc-airnet/alpine:latest
报错：ctr: content digest sha256:8fa3fa82b01e0e121843fb6db22568eb28bdc22122959be6048480aa8ac05029: not found
  • content digest......not found错误通常表示在推送镜像时，找不到指定内容摘要（content digest）的镜像。因为之前拉取镜像时只拉取了部分平台的版本，而推送的是多平台镜像。解决方法如下：重新拉取镜像，并指定--all-platforms参数拉取所有平台的版本，然后再推送镜像即OK！（私有镜像加--user value, -u value  user[:password] Registry user and password）。镜像例如alpine:latest，也必须加:latest。
ctr -n=k8s.io images pull --all-platforms  registry.cn-beijing.aliyuncs.com/atc-airnet/alpine:latest
 ctr -n=k8s.io i push   registry.cn-beijing.aliyuncs.com/atc-airnet/alpine:latest  //必需加:latest
  • 指定--all-platforms参数拉取所有平台的版本，然后再推送镜像也存在问题，原来已经pull的镜像大概率当时未加--all-platforms，就推送不了。正规方式是ctr -n=k8s.io i push --platform <具体平台amd64/arm64> <镜像名称>:<标签>
ctr -n=k8s.io i push -u sxzdsbs registry.cn-beijing.aliyuncs.com/mizy/netshoot:latest --platform amd64
  • The /v2 portion of the pull request format shown above refers to the version of the distribution api. If not included in the pull request, /v2 is added by default for all clients compliant to the distribution specification linked above.
pull myregistry.io:5000/image_name:tag_name   //The pull will resolve to,自动添加了 /v2
https://myregistry.io:5000/v2/image_name/manifests/tag_name
  • k8s/k3s集群在node通过kubelet节点下载镜像用的crictl而不是ctr（crictl 只有一个k8s.io命名空间）。crictl通过/etc/crictl.yaml配置文件（runtime-endpoint: unix:///run/containerd/containerd.sock）来与 containerd 进行交互， containerd 作为容器运行时，其默认配置文件通常是/etc/containerd/config.toml，要使用crictl拉取私有镜像并配置用户密码，需要在containerd的配置文件/etc/containerd/config.toml中进行相应设置。例如以下配置了两个仓库，一个是本地部署的core.harbor.domain，另一个私有仓库是阿里云的registry.cn-beijing.aliyuncs.com
/etc/containerd/config.toml
   [plugins."io.containerd.grpc.v1.cri".registry]
      [plugins."io.containerd.grpc.v1.cri".registry.auths]
        [plugins."io.containerd.grpc.v1.cri".registry.auths."core.harbor.domain"]
            username = "admin"
            password = "Harbor12345"
        [plugins."io.containerd.grpc.v1.cri".registry.auths."registry.cn-beijing.aliyuncs.com"]
            username = "sxzdsbs"
            password = "***"
			
      [plugins."io.containerd.grpc.v1.cri".registry.configs]
        [plugins."io.containerd.grpc.v1.cri".registry.configs."core.harbor.domain".tls]
           insecure_skip_verify = true
        [plugins."io.containerd.grpc.v1.cri".registry.configs."registry.cn-beijing.aliyuncs.com".tls]
           insecure_skip_verify = true
		   
        [plugins."io.containerd.grpc.v1.cri".registry.configs."core.harbor.domain".auth]
           username = "admin"
           password = "Harbor12345"
        [plugins."io.containerd.grpc.v1.cri".registry.configs."registry.cn-beijing.aliyuncs.com".auth]
           username = "sxzdsbs"
           password = "***"		   	  
	  
      [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."core.harbor.domain"]
          endpoint = ["core.harbor.domain"]
        [plugins."io.containerd.grpc.v1.cri".registry.mirrors."registry.cn-beijing.aliyuncs.com"]
          endpoint = ["registry.cn-beijing.aliyuncs.com"]	
测试：
//crictl pull私有仓库就不需要输入用户名密码了。
  crictl pull  registry.cn-beijing.aliyuncs.com/mizy/nginx:1.13 
//但是ctr没有从配置文件获取用户名密码，报错：authorization failed
  ctr -n=k8s.io i pull registry.cn-beijing.aliyuncs.com/mizy/nginx:1.13                             
ctr:pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed

*：由于[plugins."io.containerd.grpc.v1.cri"] 部分是专门针对 CRI 的，其他诸如 ctr、nerdctl 以及 Docker/Moby 等 containerd 客户端无法识别此部分。Kubelet通过 CRI image service API调用cri plugin（根据上面配置的仓库信息）来拉取pull应用程序容器镜像；

*：如果ctr -n=k8s.io i pull不输入用户名密码使用的话，网上说：修改/etc/containerd/config.toml文件，指定registry部分的config_path指向包含hosts.toml文件的目录；然后为私有仓库的主机命名空间创建hosts.toml文件，配置目录的默认路径通常为/etc/containerd/certs.d 在hosts.toml文件中添加相关配置。

---> 实际测试，ctr -n=k8s.io i pull必须输入用户名密码，因为hosts.toml配置文件的参数除了capabilities、skip_verify、ca等，没有设置“用户名:密码”的参数，也没有如上所说使用config.toml中对应的“用户名:密码”配置项。ctr命令实测，配置ca参数，skip_verify可以注释掉；亦或使用skip_verify = true（相当于ctr加-k参数--skip-verify：skip SSL certificate validation），就不用ca参数了。

--->config.toml
[plugins."io.containerd.grpc.v1.cri".registry] 
config_path = "/etc/containerd/certs.d" 
--->hosts.toml ：ctr的配置文件，Updates under this directory do not require restarting the containerd daemon.   
server = "https://core.harbor.domain"   
[host."https://core.harbor.domain"]
  capabilities = ["pull", "resolve", "push"]   
#  skip_verify = true     //ctr命令实测，配置ca参数，skip_verify可以注释掉
  ca = ["/etc/containerd/certs.d/core.harbor.domain/atc.pem", "/etc/containerd/certs.d/core.harbor.domain/atc.crt"]
ctr -n=k8s.io i push -u sxzdsbs registry.cn-beijing.aliyuncs.com/mizy/netshoot:latest --platform amd64
  • 注意：如下图这里选择华北2（北京），才能看到上传的镜像，因为上图Run workflow中目标源（Registry）输入的是registry.cn-beijing.aliyuncs.com注意这里是cn-beijing，假如是：registry.cn-hangzhou.aliyuncs.com/mizy/nginx，阿里云下图位置需选择华东1（杭州）。

k8s笔记18（netdata/GitHub Actions/pull-push aliyuncs）_故障排除_03

4、containerd是一个daemon（high performance container runtime），配置守护进程以及必要时使用哪些插件 容器的核心非常小。真正的功能来自插件plugins。snapshotters, runtimes, and content中的一切都是在运行时注册的插件。因为这些不同的插件如此不同，需要一种方法来为plugins提供type safe的配置。能做到这一点的唯一方法是通过配置文件而不是CLI标志。在配置文件中，可以通过[plugins.<name>]为您使用的插件集指定plugin level options，必须阅读插件特定的文档才能找到插件接受的选项。

  • The default mode "shared" will make blobs（Binary Large Object，二进制大对象） available in all namespaces once it is pulled into any namespace. 
  • Plugins are configured using the [plugins] section of containerd's config. Every plugin can have its own section using the pattern [plugins."<plugin type>.<plugin id>"].
  •  containerd has two configuration versions。version = 2必须fully qualified plugin IDs ：[plugins."io.containerd.monitor.v1.cgroups"]；而Version 1 的配置可能没有version标头，并且不需要完全限定的插件ID：[plugins.cgroups]
  • 要查看容器拥有的所有插件，使用ctr plugins ls；要查看完整的配置示例，请运行containerd config default。如果要将配置与您的配置相结合，请运行containerd config dump
  • Before containerd 2.0：在/etc/containerd/config.toml中用version = 2表示；In containerd 2.0的配置表示为version = 3。每次启动时，配置都会自动迁移到最新版本，配置文件保持不变。可以使用containerd config migrate将配置 configuration 输出为最新版本。

Configuration Version

Minimum containerd version

1

v1.0.0

2

v1.3.0

3

v2.0.0

containerd -v
containerd containerd.io 1.6.24 
version = 2
[plugins."io.containerd.grpc.v1.cri".registry]
  [plugins."io.containerd.grpc.v1.cri".registry.mirrors]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."docker.io"]
      endpoint = ["https://registry-1.docker.io"]
    [plugins."io.containerd.grpc.v1.cri".registry.mirrors."gcr.io"]
      endpoint = ["https://gcr.io"]
  [plugins."io.containerd.grpc.v1.cri".registry.configs]
    [plugins."io.containerd.grpc.v1.cri".registry.configs."gcr.io".auth]
      username = "_json_key"
      password = 'paste output from jq'

username_json_key表示将使用JSON密钥身份验证。

JSON密钥文件是一个多行文件，在文件之外使用内容作为密钥可能很麻烦。生成文件的单行格式输出是值得的。执行此操作的一种方法是使用 jq工具如下： jq -c . key.json

  • 配置cri使用Host Namespace Configs： 将registryconfig_path（CRI plugin configuration：/etc/containerd/config.toml）指向您的hosts.toml文件所在的路径。
  • 'plugins."io.containerd.grpc.v1.cri".registry' contains config related to the registry： config_path specifies a directory to look for the registry hosts configuration.The cri plugin will look for and use config_path/host-namespace/hosts.toml configs if present OR load certificate files as laid out in the Docker/Moby specific layout https://docs.docker.com/engine/security/certificates/ If config_path is not provided defaults are used.
  • *** registry.configs and registry.mirrors that were a part of containerd 1.4 are now DEPRECATED and will only be used if the config_path is not specified.
  • ！！！请注意，[plugins."io.containerd.grpc.v1.cri"] 部分是专门针对 CRI 的，其他诸如 ctr、nerdctl 以及 Docker/Moby 等 containerd 客户端无法识别此部分。
version = 2
[plugins."io.containerd.grpc.v1.cri".registry]
   config_path = "/etc/containerd/certs.d"

——>在 containerd v1.5 中，已为 ctr 客户端（供admins/developers使用的 containerd 工具）、containerd 镜像服务客户端以及诸如 kubectl 和 crictl 之类的 CRI 客户端实现了新的和额外的注册主机配置支持。对于这些客户端，配置注册中心将通过在配置目录中为每个所需的注册主机（可选）指定一个 hosts.toml 文件来完成。请注意：此目录下的更新不需要重新启动 containerd 守护进程。

k8s笔记18（netdata/GitHub Actions/pull-push aliyuncs）_基础设施_04

containerd的cri插件的架构

  • This plugin is an implementation of Kubernetes container runtime interface (CRI). Containerd operates on the same node as the Kubelet. The cri plugin inside containerd handles all CRI service requests from the Kubelet and uses containerd internals to manage containers and container images.cri插件使用容器来管理整个容器生命周期和所有容器映像。如上图所示，cri通过CNI（另一个CNCF项目）管理pod网络

CTR命令使用 Host Namespace Configs:

——在 containerd v1.5 中，针对 ctr 客户端（供管理员/开发者使用的 containerd 工具）、containerd image service客户端以及诸如 kubectl 和 crictl 之类的 CRI 客户端，已经实现了对新的和额外的registry hosts config的支持。对于这些客户端，配置registries将通过在配置目录中为每个所需的registry host（可选）指定一个 hosts.toml 文件来完成。请注意：此目录下的更新不需要重新启动 containerd 守护进程 

ctr images pull --hosts-dir "/etc/containerd/certs.d" myregistry.io:5000/image_name:tag

5、Deprecated config properties

The deprecated properties in config.toml are shown in the following table:

Property Group

Property

Deprecation release弃用版本

Target release for removal

Recommendation

[plugins."io.containerd.grpc.v1.cri"]

systemd_cgroup

containerd v1.3

containerd v2.0 ✅

Use SystemdCgroup in runc options (see below)

[plugins."io.containerd.grpc.v1.cri".containerd]

untrusted_workload_runtime

containerd v1.2

containerd v2.0 ✅

Create untrusted runtime in runtimes

[plugins."io.containerd.grpc.v1.cri".containerd]

default_runtime

containerd v1.3

containerd v2.0 ✅

Use default_runtime_name

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.*]

runtime_engine

containerd v1.3

containerd v2.0 ✅

Use runtime v2

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.*]

runtime_root

containerd v1.3

containerd v2.0 ✅

Use options.Root

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.*.options]

CriuPath

containerd v1.7

containerd v2.0 ✅

Set $PATH to the criu binary

[plugins."io.containerd.grpc.v1.cri".registry]

auths

containerd v1.3

containerd v2.1

Use ImagePullSecrets. See also #8228.

[plugins."io.containerd.grpc.v1.cri".registry]

configs

containerd v1.5

containerd v2.1

Use config_path

[plugins."io.containerd.grpc.v1.cri".registry]

mirrors

containerd v1.5

containerd v2.1

Use config_path

[plugins."io.containerd.tracing.processor.v1.otlp"]

endpoint, protocol, insecure

containerd v1.6.29

containerd v2.0

Use OTLP environment variables, e.g. OTEL\_EXPORTER\_OTLP\_TRACES\_ENDPOINT, OTEL\_EXPORTER\_OTLP\_PROTOCOL, OTEL\_SDK\_DISABLED

[plugins."io.containerd.internal.v1.tracing"]

service_name, sampling_ratio

containerd v1.6.29

containerd v2.0

Instead use OTel environment variables, e.g. OTEL\_SERVICE\_NAME, OTEL\_TRACES\_SAMPLER\*

**Note：containerd v2.1版本使用config_path替代 config.toml 中这几个配置项

[plugins."io.containerd.grpc.v1.cri".registry]的configs和mirrors；使用ImagePullSecrets替代 config.toml 中的[plugins."io.containerd.grpc.v1.cri".registry]的auths

5.1、创建Pod时利用 Secret信息从private container image registry 或 repository中拉取镜像。Kubernetes 集群使用 kubernetes.io/dockerconfigjson 类型的 Secret 来与容器registry进行身份验证，以拉取私有镜像。 如果您已经运行了 docker login，您可以将该凭证复制到 Kubernetes 中，利用特定类型的 Secret 与容器registry进行认证从而获取私有镜像，如果之前已进行 docker login 操作，可以将相关凭证复制到 Kubernetes 里。 

kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson
# kubectl get secret regcred --output="jsonpath={.data.\.dockerconfigjson}" | base64 --decode
{"auths":{"core.harbor.domain/library":{"username":"admin","password":"Harbor12345","email":"chaisd63@163.com","auth":"YWRtaW46SGFyYm9yMTIzNDU="}}}
# echo "YWRtaW46SGFyYm9yMTIzNDU=" | base64 --decode
admin:Harbor12345
# cat ~/.docker/config.json
{
        "auths": {
                "core.harbor.domain": {
                        "auth": "YWRtaW46SGFyYm9yMTIzNDU="
                }
        }
}
  • Notice that the Secret data contains the authorization token similar to your local ~/.docker/config.json file.