chinese直男口爆体育生外卖, 99久久er热在这里只有精品99, 又色又爽又黄18禁美女裸身无遮挡, gogogo高清免费观看日本电视,私密按摩师高清版在线,人妻视频毛茸茸,91论坛 兴趣闲谈,欧美 亚洲 精品 8区,国产精品久久久久精品免费

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

Containerd的Bug導致容器被重建!如何避免?

openEuler ? 來源:openEuler ? 2023-02-10 13:55 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

最近我們關注到一個關于containerd 運行時的issue

https://github.com/containerd/containerd/issues/7843),該問題在 containerd v1.6.9/v1.5.15 被引入。出現(xiàn)的問題是,當 containerd 重啟后,在其中運行的 Pod 元數(shù)據(jù)中關于網絡相關的數(shù)據(jù)(如 pod ip)丟失,核心原因在于部分數(shù)據(jù)沒有落盤。

受影響的版本:

  • v1.6.9 ~ v1.6.14,問題在 v1.6.15 版本中被修復。

  • v1.5.15 ~ v1.5.16,問題在 v1.5.17 版本中被修復。

通過以下步驟,可以快速重現(xiàn)該問題,并驗證該問題的修復情況。

本文使用 rke2 為例進行演示,版本為 rke2 v1.24.9+rke2r1,該版本使用了 k3s-containerd v1.6.12-k3s1,受該 containerd 問題影響。

在 containerd 的默認行為中,重啟 containerd 服務不會影響正在運行的業(yè)務容器,并在啟動容器時,通過將容器父進程綁定 Pid 1 的方式進行體現(xiàn)。即使使用 systemctl 對服務進行重啟,也不會影響到已經在運行的容器狀態(tài)。

——問題重現(xiàn)——
#配置rke2使用國內鏡像倉庫下載鏡像
mkdir-p/etc/rancher/rke2
echo"system-default-registry:registry.cn-hangzhou.aliyuncs.com">/etc/rancher/rke2/config.yaml
#使用命令安裝rke2,以下命令使用了我們在國內維護的rke2安裝鏡像腳本,會從aliyunOSS下載RKE2資源
curl-sfLhttps://rancher-mirror.oss-cn-beijing.aliyuncs.com/rke2/install.sh|INSTALL_RKE2_MIRROR=cnINSTALL_RKE2_VERSION=v1.24.9+rke2r1sh-
#[INFO]usingv1.24.9-rke2r1asrelease
#[INFO]downloadingchecksumsathttps://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/sha256sum-amd64.txt
#[INFO]downloadingtarballathttps://rancher-mirror.rancher.cn/rke2/releases/download/v1.24.9-rke2r1/rke2.linux-amd64.tar.gz
#[INFO]verifyingtarball
#[INFO]unpackingtarballfileto/usr/local

#啟動rke2服務,并等待服務啟動成功
systemctlstartrke2-server

#配置rke2相關的PATH路徑以及kube-config路徑
exportKUBECONFIG=/etc/rancher/rke2/rke2.yaml
exportPATH=/var/lib/rancher/rke2/bin:$PATH

#使用kubectl查詢當前集群狀態(tài)
kubectlgetpo-A|greprke2-metrics-server-5b987d776b-gqxv9

#kube-systemrke2-metrics-server-5b987d776b-gqxv91/1Running015m

至此,rke2 單節(jié)點服務啟動完成,但我們的目標是 containerd,接下來繼續(xù)操作:

#配置containerd相關環(huán)境變量
exportCRI_CONFIG_FILE=/var/lib/rancher/rke2/agent/etc/containerd/config.tomlCONTAINER_RUNTIME_ENDPOINT=unix:///var/run/k3s/containerd/containerd.sock
#使用crictl查詢pods以及container信息
crictlpods|greprke2-metrics-server

#bfad44591742318minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system0(default)

crictlps|greprke2-metrics-server

#db5d6392a310ef6dc23a68f5fb18minutesagoRunningmetrics-server0bfad445917423rke2-metrics-server-5b987d776b-gqxv9

我們以 metrics-server 的 pod 為例,查詢 pod 詳情中的網絡部分內容,并對 containerd 進行重啟,對問題進行重現(xiàn):

#查詢metrics-serverpod的詳情
crictlinspectpbfad445917423|jq.status.network

#{
#"additionalIps":[],
#"ip":"10.42.0.6"
#}

#停止rke2-server服務并單獨啟動containerd,避免kubelet影響重現(xiàn)結果
systemctlstoprke2-server
#單獨啟動containerd
containerd-c/var/lib/rancher/rke2/agent/etc/containerd/config.toml-a/run/k3s/containerd/containerd.sock--state/run/k3s/containerd--root/var/lib/rancher/rke2/agent/containerd

通過新的 terminal,使用 crictl 查詢 containerd 運行狀態(tài)

crictlpods|greprke2-metrics-server

#bfad44591742324minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system0(default)

#再次查詢metrics-serverpod詳情
crictlinspectpbfad445917423|jq.status.network

#{
#"additionalIps":[],
#"ip":""
#}

從最后的返回結果可以看出,containerd 重啟后容器的 IP 丟失。

——問題影響——

通過在上述例子中重啟 rke2-server 可以看到,由于 ip 信息丟失,導致了業(yè)務容器被重建,帶來了業(yè)務中斷的風險。

#在中斷containerd進程后,重啟rke2-server進程(以下數(shù)據(jù)為重新驗證后的數(shù)據(jù))
systemctlrestartrke2-server
kubectlgetpo-A|greprke2-metrics-server-5b987d776b-8vg69

#kube-systemrke2-metrics-server-5b987d776b-8vg691/1Running2(115sago)23m

crictlpods|greprke2-metrics-server

#caba6d8d1582341secondsagoReadyrke2-metrics-server-5b987d776b-8vg69kube-system1(default)
#2dec6a11fd36f22minutesagoNotReadyrke2-metrics-server-5b987d776b-8vg69kube-system0(default)

可以看到,在 rke2-server 重啟后,使用了 cni 的 pod 發(fā)生了重啟,在 crictl pods 返回中可以看到重新創(chuàng)建的 pods。

——問題修復驗證——

下載新版本 containerd,這次驗證使用 k3s-containerd v1.6.14+k3s1。該版本為 Rancher 在 containerd v1.6.15 發(fā)布前緊急發(fā)布的修復補丁版本。

#拉取新鏡像
dockerpullrancher/hardened-containerd:v1.6.14-k3s1-build20230105
mkdircontainer-new
cdcontainer-new
#從鏡像中獲取新版本containerd
dockerrun--rm-it-v${PWD}:/outputrancher/hardened-containerd:v1.6.14-k3s1-build20230105cp-r/usr/local/bin/output
./output/bin/containerd--version
#containerdgithub.com/k3s-io/containerdv1.6.14-k3s16f9c63d571f5026e85a0768f0f2ef03d1c8dbc6e

#關閉當前運行的容器
pkill-f/var/lib/rancher/rke2/data/v1.24.9-rke2r1-d4d8faf800d0/bin/containerd-shim-runc-v2
#替換containerdbinary版本
cp./bin/*/var/lib/rancher/rke2/bin
/var/lib/rancher/rke2/bin/containerd--version
#containerdgithub.com/k3s-io/containerdv1.6.14-k3s16f9c63d571f5026e85a0768f0f2ef03d1c8dbc6e

#啟動rke2
systemctlstartrke2-server
#此時使用crictl查詢新的metrics-serverpod
crictlpods|grep"Ready"|grepmetrics-server
#ad8b101f819df3minutesagoReadyrke2-metrics-server-5b987d776b-gqxv9kube-system1(default)

#停止rke2并使用命令行啟動containerd
systemctlstoprke2-server
containerd-c/var/lib/rancher/rke2/agent/etc/containerd/config.toml-a/run/k3s/containerd/containerd.sock--state/run/k3s/containerd--root/var/lib/rancher/rke2/agent/containerd

通過新的 terminal,使用 crictl 查詢 containerd 運行狀態(tài)

crictlinspectpad8b101f819df|jq.status.network
#{
#"additionalIps":[],
#"ip":"10.42.0.13"
#}

可以看到 containerd 重啟后,pod ip 沒有丟失。

—— RKE2 與 RFO——

RKE2 以下版本受該 issue 影響:

  • v1.23.15+rke2r1

  • v1.24.9+rke2r1

  • v1.25.5+rke2r1

  • v1.26.0+rke2r1

該 issue 在 2022 年 12 月 20 日被提交,RKE2 團隊在 2023 年 1 月 6 日緊急合并了 containerd 中修復該 issue 的 commit,發(fā)布了 k3s-containerd v1.6.14+k3s1 版本,并發(fā)布了新的 rke2 rc 版本進行測試驗證。

最終在 1 月 11 日,RKE2 團隊發(fā)布以下已經修復 containerd 問題的版本:

  • v1.23.16+rke2r1

  • v1.24.9+rke2r2

  • v1.25.5+rke2r2

  • v1.26.0+rke2r2

RFO 是 Rancher For openEuler 的縮寫,顧名思義,目的在于面向 openEuler 打造 Rancher 基礎平臺。

由于 RFO 版本發(fā)布周期在 RKE2 之后,RFO 并沒有受到該 issue 影響,并在近期發(fā)布了以下版本:

  • v1.23.16+rfor1

  • v1.24.9+rfor1

  • v1.24.10+rfor1

  • v1.25.5+rfor1

  • v1.25.6+rfor1

  • v1.26.0+rfor1

  • v1.26.1+rfor1

—— 寫在最后 ——

由于操作系統(tǒng)的軟件包發(fā)布存在一定的時間延后性,在大部分情況下都無法及時修復軟件出現(xiàn)的問題。像 CVE、功能缺陷等問題都比較緊急,等待操作系統(tǒng)供應商提供修復版本將是一個漫長的過程,甚至有時候由于一些限制,操作系統(tǒng)提供商無法提供新版本的軟件包,這會給系統(tǒng)運行帶來不確定因素。

在這種情況下,將軟件自身依賴的組件打包到自己的 rootfs 中進行分發(fā),能更好地對其進行管理和升級,避免給系統(tǒng)運行帶來風險以及潛在的損失。


審核編輯 :李倩


聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 操作系統(tǒng)

    關注

    37

    文章

    7136

    瀏覽量

    125470
  • 容器
    +關注

    關注

    0

    文章

    509

    瀏覽量

    22437
  • BUG
    BUG
    +關注

    關注

    0

    文章

    156

    瀏覽量

    16011

原文標題:Containerd 的 Bug 導致容器被重建!如何避免?

文章出處:【微信號:openEulercommunity,微信公眾號:openEuler】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    如何避免容器充電會時導致的涌入電流

    在大多數(shù)系統(tǒng)中,為了確保電源軌電壓不會出現(xiàn)壓降,電容器遍布于整個設計中。當電源剛剛被施加到系統(tǒng)中時,為這些電容器充電會導致一個涌入電流,如果不加以處理的話,這個電流會造成數(shù)個系統(tǒng)問題。 圖1顯示
    的頭像 發(fā)表于 05-31 09:39 ?1.2w次閱讀
    如何<b class='flag-5'>避免</b>電<b class='flag-5'>容器</b>充電會時<b class='flag-5'>導致</b>的涌入電流

    Containerd常見命令操作

    作為接替 Docker 運行時的 Containerd 在早在 Kubernetes1.7 時就能直接與 Kubelet 集成使用,只是大部分時候我們因熟悉 Docker,在部署集群時采用了默認
    的頭像 發(fā)表于 08-30 10:08 ?5591次閱讀

    容器擊穿的multism模型如何設計

    本帖最后由 yangk1990 于 2013-3-8 17:11 編輯 本人初學,需要設計一個示波器觀測電容器擊穿的波形(或者可變電容逐漸減小到變成導體也行),但電容器的擊穿著實不會...希望大神們能夠指點一下!
    發(fā)表于 03-07 20:38

    由于InnoDB MVCC導致的并發(fā)BUG介紹

    [原]記錄一個由于InnoDB MVCC導致的并發(fā)BUG
    發(fā)表于 07-17 09:46

    8 分鐘入門 K8s | 詳解容器基本概念

    提供一個靈活的插件化管理。而 shim 就是針對于不同的容器運行時所開發(fā)的,這樣就能夠從 containerd 中脫離出來,通過插件的形式進行管理。其次,因為 shim 插件化的實現(xiàn),使其能夠
    發(fā)表于 09-17 15:29

    蘋果IOS10.3.1正式版緊急發(fā)布,修復BUG

    在3月28日發(fā)布的10.3正式版中被發(fā)現(xiàn)存在一個BUG。這一BUG的存在可能導致此前已經關閉的iCloud服務自動開啟。蘋果方面并沒有解
    發(fā)表于 04-05 15:03 ?1898次閱讀

    IOS 10.3.1正式版緊急發(fā)布,修復BUG

    在3月28日發(fā)布的10.3正式版中被發(fā)現(xiàn)存在一個BUG。這一BUG的存在可能導致此前已經關閉的iCloud服務自動開啟。蘋果方面并沒有解
    發(fā)表于 04-05 16:13 ?856次閱讀
    IOS 10.3.1正式版緊急發(fā)布,修復<b class='flag-5'>BUG</b>

    重磅!阿里巴巴工程師獲得 containerd 社區(qū)席位,與社區(qū)共建云時代容器標準

    重磅!阿里巴巴工程師獲得 containerd 社區(qū)席位,與社區(qū)共建云時代容器標準11 月 29 日,CNCF containerd 社區(qū)正式宣布:兩位阿里巴巴工程師正式獲得 containe
    發(fā)表于 12-11 17:25 ?466次閱讀

    MDK-ARM V5.28的Bug修復了嗎 ?

    MDK-ARM V5.28的Bug修復了嗎?
    的頭像 發(fā)表于 03-01 12:01 ?2550次閱讀

    微軟又證實一新Bug Windows 10或導致無法訪問互聯(lián)網

    據(jù)外媒報道稱,微軟證實了一個新的Bug,那就是Windows 10存在一個可能導致無法訪問互聯(lián)網的問題。
    的頭像 發(fā)表于 03-28 11:20 ?2412次閱讀

    微軟Win10兩個新Bug曝光:可以濫用于各種攻擊

    ,一位 Windows 安全研究人員在 Twitter 上披露了兩個 Bug,可以濫用于各種攻擊。 第一個 Bug 允許無權限的用戶或程序輸入一條命令,導致 NTFS 硬盤
    的頭像 發(fā)表于 01-19 17:00 ?1508次閱讀

    Containerd控制runC的守護進程

    ./oschina_soft/containerd.zip
    發(fā)表于 05-11 10:05 ?0次下載
    <b class='flag-5'>Containerd</b>控制runC的守護進程

    Containerd基礎用法

    從 Docker 1.11 版本開始,Docker 容器運行就不是簡單通過 Docker Daemon 來啟動了,而是通過集成containerd、runc等多個組件來完成的。 雖然Docker
    的頭像 發(fā)表于 04-11 10:50 ?1028次閱讀

    一個冗余電路導致BUG

      昨天解了一個BUG,一個低級錯誤導致BUG,一個冗余電路導致BUG,寫寫做個記錄。
    的頭像 發(fā)表于 05-14 15:28 ?1200次閱讀
    一個冗余電路<b class='flag-5'>導致</b>的<b class='flag-5'>BUG</b>

    服務器數(shù)據(jù)恢復-重建MDisk導致VDisk丟失的數(shù)據(jù)恢復案例

    重建MDisk導致對應的存儲池中的VDisk丟失,導致Solaris操作系統(tǒng)中的Oracle數(shù)據(jù)庫無法使用。
    的頭像 發(fā)表于 07-26 15:26 ?495次閱讀