色哟哟视频在线观看-色哟哟视频在线-色哟哟欧美15最新在线-色哟哟免费在线观看-国产l精品国产亚洲区在线观看-国产l精品国产亚洲区久久

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

完善資料讓更多小伙伴認(rèn)識(shí)你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

Pod是如何在底層實(shí)現(xiàn)的?如何使用Docker創(chuàng)建Pod?

馬哥Linux運(yùn)維 ? 來源:馬哥Linux運(yùn)維 ? 2023-08-14 10:33 ? 次閱讀

剛開始接觸 Kubernetes 時(shí),你學(xué)到的第一件事就是每個(gè) Pod 都有一個(gè)唯一的 IP 和主機(jī)名,并且在同一個(gè) Pod 中,容器可以通過 localhost 相互通信。所以,顯而易見,一個(gè) Pod 就像一個(gè)微型的服務(wù)器。

但是,過段時(shí)間,你會(huì)發(fā)現(xiàn) Pod 中的每個(gè)容器都有一個(gè)隔離的文件系統(tǒng),并且從一個(gè)容器內(nèi)部,你看不到在同一 Pod 的其他容器中運(yùn)行的進(jìn)程。好吧!也許 Pod 不是一個(gè)微型的服務(wù)器,而只是一組具有共享網(wǎng)絡(luò)堆棧的容器。

但隨后你會(huì)了解到,Pod 中的容器可以通過共享內(nèi)存進(jìn)行通信!所以,在容器之間,網(wǎng)絡(luò)命名空間不是唯一可以共享的東西……

基于最后的發(fā)現(xiàn),所以,我決定深入了解:

Pod 是如何在底層實(shí)現(xiàn)的

Pod 和 Container 之間的實(shí)際區(qū)別是什么

如何使用 Docker 創(chuàng)建 Pod

在此過程中,我希望它能幫助我鞏固我的 Linux、Docker 和 Kubernetes 技能。

探索 Container

OCI 運(yùn)行時(shí)規(guī)范并不將容器實(shí)現(xiàn)僅限于 Linux 容器,即使用 namespace 和 cgroup 實(shí)現(xiàn)的容器。但是,除非另有明確說明,否則本文中的容器一詞指的是這種相當(dāng)傳統(tǒng)的形式。

設(shè)置實(shí)驗(yàn)環(huán)境(playground)

在了解構(gòu)成容器的 namespace 和 cgroups 之前,讓我們快速設(shè)置一個(gè)實(shí)驗(yàn)環(huán)境:

$ cat > Vagrantfile <

最后讓我們啟動(dòng)一個(gè)容器:

$ docker run --name foo --rm -d --memory='512MB' --cpus='0.5' nginx

探索容器的 namespace

首先我們來看一下,當(dāng)容器啟動(dòng)后,哪些隔離原語(primitives)被創(chuàng)建了:

# Look up the container in the process tree.
$ ps auxf
USER       PID  ...  COMMAND
...
root      4707       /usr/bin/containerd-shim-runc-v2 -namespace moby -id cc9466b3e...
root      4727        \_ nginx: master process nginx -g daemon off;
systemd+  4781            \_ nginx: worker process
systemd+  4782            \_ nginx: worker process


# Find the namespaces used by 4727 process.
$ sudo lsns
        NS TYPE   NPROCS   PID USER    COMMAND
...
4026532157 mnt         3  4727 root    nginx: master process nginx -g daemon off;
4026532158 uts         3  4727 root    nginx: master process nginx -g daemon off;
4026532159 ipc         3  4727 root    nginx: master process nginx -g daemon off;
4026532160 pid         3  4727 root    nginx: master process nginx -g daemon off;
4026532162 net         3  4727 root    nginx: master process nginx -g daemon off;

我們可以看到用于隔離以上容器的命名空間是以下這些:

mnt(掛載):#容器有一個(gè)隔離的掛載表。
uts(Unix 時(shí)間共享):#容器擁有自己的 hostname 和 domain。
ipc(進(jìn)程間通信):#容器內(nèi)的進(jìn)程可以通過系統(tǒng)級(jí) IPC 和同一容器內(nèi)的其他進(jìn)程進(jìn)行通信。
pid(進(jìn)程 ID):#容器內(nèi)的進(jìn)程只能看到在同一容器內(nèi)或擁有相同的 PID 命名空間的其他進(jìn)程。
net(網(wǎng)絡(luò)):#容器擁有自己的網(wǎng)絡(luò)堆棧。

注意,用戶(user)命名空間沒有被使用,OCI 運(yùn)行時(shí)規(guī)范提及了對(duì)用戶命名空間的支持。不過,雖然 Docker 可以將此命名空間用于其容器,但由于固有的限制,它默認(rèn)情況下沒有使用。因此,容器中的 root 用戶很可能是主機(jī)系統(tǒng)中的 root 用戶。

另一個(gè)沒有出現(xiàn)在這里的命名空間是 cgroup。我花了一段時(shí)間才理解 cgroup 命名空間與 cgroups 機(jī)制(mechanism)的不同。Cgroup 命名空間僅提供一個(gè)容器的 cgroup 層次結(jié)構(gòu)的孤立視圖。同樣,Docker 也支持將容器放入私有 cgroup 命名空間,但默認(rèn)情況下沒有這么做。

探索容器的 cgroups

Linux 命名空間可以讓容器中的進(jìn)程認(rèn)為自己是在一個(gè)專用的機(jī)器上運(yùn)行。但是,看不到別的進(jìn)程并不意味著不會(huì)受到其他進(jìn)程的影響。一些耗資源的進(jìn)程可能會(huì)意外的過多消耗宿主機(jī)上面共享的資源。

這時(shí)候就需要 cgroups 的幫助!

可以通過檢查 cgroup 虛擬文件系統(tǒng)中的相應(yīng)子樹來查看給定進(jìn)程的 cgroups 限制。Cgroupfs 通常被掛在 /sys/fs/cgroup 目錄,并且進(jìn)程特定相關(guān)的部分可以在 /proc//cgroup 中查看:

PID=$(docker inspect --format '{{.State.Pid}}' foo)


# Check cgroupfs node for the container main process (4727).
$ cat /proc/${PID}/cgroup
11:freezer:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
10:blkio:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
9:rdma:/
8:pids:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
7:devices:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
6:cpuset:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
5:cpu,cpuacct:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
4:memory:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
3:net_cls,net_prio:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
2:perf_event:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
1:name=systemd:/docker/cc9466b3eb67ca374c925794776aad2fd45a34343ab66097a44594b35183dba0
0::/system.slice/containerd.service

似乎 Docker 使用 /docker/模式。好吧,不管怎樣:

ID=$(docker inspect --format '{{.Id}}' foo)


# Check the memory limit.
$ cat /sys/fs/cgroup/memory/docker/${ID}/memory.limit_in_bytes
536870912  # Yay! It's the 512MB we requested!


# See the CPU limits.
ls /sys/fs/cgroup/cpu/docker/${ID}

有趣的是在不明確設(shè)置任何資源限制的情況下啟動(dòng)容器都會(huì)配置一個(gè) cgroup。實(shí)際中我沒有檢查過,但我的猜測是默認(rèn)情況下,CPU 和 RAM 消耗不受限制,Cgroups 可能用來限制從容器內(nèi)部對(duì)某些設(shè)備的訪問。

這是我在調(diào)查后腦海中呈現(xiàn)的容器:

fb04e882-39d9-11ee-9e74-dac502259ad0.jpg

探索 Pod

現(xiàn)在,讓我們來看看 Kubernetes Pod。與容器一樣,Pod 的實(shí)現(xiàn)可以在不同的 CRI 運(yùn)行時(shí)(runtime)之間變化。例如,當(dāng) Kata 容器被用來作為一個(gè)支持的運(yùn)行時(shí)類時(shí),某些 Pod 可以就是真實(shí)的虛擬機(jī)了!并且正如預(yù)期的那樣,基于 VM 的 Pod 與傳統(tǒng) Linux 容器實(shí)現(xiàn)的 Pod 在實(shí)現(xiàn)和功能方面會(huì)有所不同。

為了保持容器和 Pod 之間公平比較,我們會(huì)在使用 ContainerD/Runc 運(yùn)行時(shí)的 Kubernetes 集群上進(jìn)行探索。這也是 Docker 在底層運(yùn)行容器的機(jī)制。

設(shè)置實(shí)驗(yàn)環(huán)境(playground)

這次我們使用基于 VirtualBox driver 和 Containd 運(yùn)行時(shí)的 minikube 來設(shè)置實(shí)驗(yàn)環(huán)境。要快速安裝 minikube 和 kubectl,我們可以使用 Alex Ellis 編寫的 arkade 工具:

# Install arkade ()
$ curl -sLS https://get.arkade.dev | sh


$ arkade get kubectl minikube


$ minikube start --driver virtualbox --container-runtime containerd

實(shí)驗(yàn)的 Pod,可以按照下面的方式設(shè)置:

$ kubectl --context=minikube apply -f - <

探索 Pod 的容器

實(shí)際的 Pod 檢查應(yīng)在 Kubernetes 集群節(jié)點(diǎn)上進(jìn)行:

$ minikube ssh

讓我們看看那里 Pod 的進(jìn)程:

$ ps auxf
USER       PID  ...  COMMAND
...
root      4947         \_ containerd-shim -namespace k8s.io -workdir /mnt/sda1/var/lib/containerd/...
root      4966             \_ /pause
root      4981         \_ containerd-shim -namespace k8s.io -workdir /mnt/sda1/var/lib/containerd/...
root      5001             \_ /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
root      5016                 \_ /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
root      5018         \_ containerd-shim -namespace k8s.io -workdir /mnt/sda1/var/lib/containerd/...
100       5035             \_ /bin/sleep 3650d

基于運(yùn)行的時(shí)間,上述三個(gè)進(jìn)程組很有可能是在 Pod 啟動(dòng)期間創(chuàng)建。這很有意思,因?yàn)樵谇鍐挝募校挥袃蓚€(gè)容器,httpbin 和 sleep。

可以使用名為 ctr 的 ContainerD 命令行來交叉檢查上述的發(fā)現(xiàn):

$ sudo ctr --namespace=k8s.io containers ls
CONTAINER      IMAGE                                   RUNTIME
...
097d4fe8a7002  docker.io/curlimages/curl@sha256:1a220  io.containerd.runtime.v1.linux
...
dfb1cd29ab750  docker.io/kennethreitz/httpbin:latest   io.containerd.runtime.v1.linux
...
f0e87a9330466  k8s.gcr.io/pause:3.1                    io.containerd.runtime.v1.linux

的確是三個(gè)容器被創(chuàng)建了。同時(shí),使用另一個(gè)和 CRI 運(yùn)行時(shí)監(jiān)控的命令行 crictl 檢測發(fā)現(xiàn),僅僅只有兩個(gè)容器:

$ sudo crictl ps
CONTAINER      IMAGE          CREATED            STATE    NAME     ATTEMPT  POD ID
097d4fe8a7002  bcb0c26a91c90  About an hour ago  Running  sidecar  0        f0e87a9330466
dfb1cd29ab750  b138b9264903f  About an hour ago  Running  app      0        f0e87a9330466

但是注意,上述的 POD ID 字段和 ctr 輸出的 pause:3.1 容器 id 一致。好吧,看上去這個(gè) Pod 是一個(gè)輔助容器。所以,它有什么用呢?

我還沒有注意到在 OCI 運(yùn)行時(shí)規(guī)范中有和 Pod 相對(duì)應(yīng)的東西。因此,當(dāng)我對(duì) Kubernetes API 規(guī)范提供的信息不滿意時(shí),我通常直接進(jìn)入 Kubernetes Container Runtime 接口(CRI)Protobuf 文件中查找相應(yīng)的信息:

// kubelet expects any compatible container runtime
// to implement the following gRPC methods:


service RuntimeService {
    ...
    rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}    
    rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}    
    rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}    
    rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}
    rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}


    rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}
    rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}    
    rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}    
    rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}
    rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}    
    rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}    
    rpc UpdateContainerResources(UpdateContainerResourcesRequest) returns (UpdateContainerResourcesResponse) {}    
    rpc ReopenContainerLog(ReopenContainerLogRequest) returns (ReopenContainerLogResponse) {}


    // ...    
}


message CreateContainerRequest {
    // ID of the PodSandbox in which the container should be created.
    string pod_sandbox_id = 1;
    // Config of the container.
    ContainerConfig config = 2;
    // Config of the PodSandbox. This is the same config that was passed
    // to RunPodSandboxRequest to create the PodSandbox. It is passed again
    // here just for easy reference. The PodSandboxConfig is immutable and
    // remains the same throughout the lifetime of the pod.
    PodSandboxConfig sandbox_config = 3;
}

所以,Pod 實(shí)際上就是由沙盒以及在沙盒中運(yùn)行的容器組成的。沙盒管理 Pod 中所有容器的常用資源,pause 容器會(huì)在 RunPodSandbox() 調(diào)用中被啟動(dòng)。簡單的互聯(lián)網(wǎng)搜索就發(fā)現(xiàn)了該容器僅僅是一個(gè) idle 進(jìn)程。

探索 Pod 的命名空間

下面就是集群節(jié)點(diǎn)上的命名空間:

$ sudo lsns
        NS TYPE   NPROCS   PID USER            COMMAND
4026532614 net         4  4966 root            /pause
4026532715 mnt         1  4966 root            /pause
4026532716 uts         4  4966 root            /pause
4026532717 ipc         4  4966 root            /pause
4026532718 pid         1  4966 root            /pause
4026532719 mnt         2  5001 root            /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
4026532720 pid         2  5001 root            /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
4026532721 mnt         1  5035 100             /bin/sleep 3650d
4026532722 pid         1  5035 100             /bin/sleep 3650d

前面第一部分很像 Docker 容器,pause 容器有五個(gè)命名空間:net、mnt、uts、ipc 以及 pid。但是很明顯,httpbin 和 sleep 容器僅僅有兩個(gè)命名空間:mnt 和 pid。這是怎么回事?

事實(shí)證明,lsns 不是檢查進(jìn)程名稱空間的最佳工具。相反,要檢查某個(gè)進(jìn)程使用的命名空間,可以參考 /proc/${pid}/ns 位置:

# httpbin container
sudo ls -l /proc/5001/ns
...
lrwxrwxrwx 1 root root 0 Oct 24 14:05 ipc -> 'ipc:[4026532717]'
lrwxrwxrwx 1 root root 0 Oct 24 14:05 mnt -> 'mnt:[4026532719]'
lrwxrwxrwx 1 root root 0 Oct 24 14:05 net -> 'net:[4026532614]'
lrwxrwxrwx 1 root root 0 Oct 24 14:05 pid -> 'pid:[4026532720]'
lrwxrwxrwx 1 root root 0 Oct 24 14:05 uts -> 'uts:[4026532716]'


# sleep container
sudo ls -l /proc/5035/ns
...
lrwxrwxrwx 1 100 101 0 Oct 24 14:05 ipc -> 'ipc:[4026532717]'
lrwxrwxrwx 1 100 101 0 Oct 24 14:05 mnt -> 'mnt:[4026532721]'
lrwxrwxrwx 1 100 101 0 Oct 24 14:05 net -> 'net:[4026532614]'
lrwxrwxrwx 1 100 101 0 Oct 24 14:05 pid -> 'pid:[4026532722]'
lrwxrwxrwx 1 100 101 0 Oct 24 14:05 uts -> 'uts:[4026532716]'

雖然不太容易去注意到,但 httpbin 和 sleep 容器實(shí)際上重用了 pause 容器的 net、uts 和 ipc 命名空間!

我們可以用 crictl 交叉檢測驗(yàn)證:

# Inspect httpbin container.
$ sudo crictl inspect dfb1cd29ab750
{
  ...
  "namespaces": [
    {
      "type": "pid"
    },
    {
      "type": "ipc",
      "path": "/proc/4966/ns/ipc"
    },
    {
      "type": "uts",
      "path": "/proc/4966/ns/uts"
    },
    {
      "type": "mount"
    },
    {
      "type": "network",
      "path": "/proc/4966/ns/net"
    }
  ],
  ...
}


# Inspect sleep container.
$ sudo crictl inspect 097d4fe8a7002
...

我認(rèn)為上述發(fā)現(xiàn)完美的解釋了同一個(gè) Pod 中容器具有的能力:

能夠互相通信

通過 localhost 和/或

使用 IPC(共享內(nèi)存,消息隊(duì)列等)

共享 domain 和 hostname

然而,在看過所有這些命名空間如何在容器之間自由重用之后,我開始懷疑默認(rèn)邊界可以被打破。實(shí)際上,在對(duì) Pod API 規(guī)范的更深入閱讀后發(fā)現(xiàn),將 shareProcessNamespace 標(biāo)志設(shè)置為 true 時(shí),Pod 的容器將擁有四個(gè)通用命名空間,而不是默認(rèn)的三個(gè)。但是有一個(gè)更令人震驚的發(fā)現(xiàn) hostIPC、hostNetwork 和 hostPID 標(biāo)志可以使容器使用相應(yīng)主機(jī)的命名空間。

有趣的是,CRI API 規(guī)范似乎更加靈活。至少在語法上,它允許將 net、pid 和 ipc 命名空間限定為 CONTAINER、POD 或 NODE。因此,可以構(gòu)建一個(gè) Pod 使其容器無法通過 localhost 相互通信 。

探索 Pod 的 cgroups

Pod 的 cgroups 是什么樣的?systemd-cgls 可以很好地可視化 cgroups 層次結(jié)構(gòu):

$ sudo systemd-cgls
Control group /:
-.slice
├─kubepods
│ ├─burstable
│ │ ├─pod4a8d5c3e-3821-4727-9d20-965febbccfbb
│ │ │ ├─f0e87a93304666766ab139d52f10ff2b8d4a1e6060fc18f74f28e2cb000da8b2
│ │ │ │ └─4966 /pause
│ │ │ ├─dfb1cd29ab750064ae89613cb28963353c3360c2df913995af582aebcc4e85d8
│ │ │ │ ├─5001 /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
│ │ │ │ └─5016 /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
│ │ │ └─097d4fe8a7002d69d6c78899dcf6731d313ce8067ae3f736f252f387582e55ad
│ │ │   └─5035 /bin/sleep 3650d
...

所以,Pod 本身有一個(gè)父節(jié)點(diǎn)(Node),每個(gè)容器也可以單獨(dú)調(diào)整。這符合我的預(yù)期,因?yàn)樵?Pod 清單中,可以為 Pod 中的每個(gè)容器單獨(dú)設(shè)置資源限制。

此刻,我腦海中的 Pod 看起來是這樣的:

fb17b700-39d9-11ee-9e74-dac502259ad0.jpg

利用 Docker 實(shí)現(xiàn) Pod

如果 Pod 的底層實(shí)現(xiàn)是一組具有共同 cgroup 父級(jí)的半融合(emi-fused)容器,是否可以使用 Docker 生產(chǎn)類似 Pod 的構(gòu)造?

最近我嘗試做了一些類似的事情來讓多個(gè)容器監(jiān)聽同一個(gè)套接字,我知道 Docker 可以通過 docker run —network container:語法來創(chuàng)建一個(gè)可以使用已存在的網(wǎng)絡(luò)命名空間容器。但我也知道 OCI 運(yùn)行時(shí)規(guī)范只定義了 create 和 start 命令。

因此,當(dāng)你使用 docker exec在現(xiàn)有容器中執(zhí)行命令時(shí),實(shí)際上是在運(yùn)行(即 create 然后 start)一個(gè)全新的容器,該容器恰好重用了目標(biāo)容器的所有命名空間。這讓我非常有信心可以使用標(biāo)準(zhǔn) Docker 命令生成 Pod。

我們可以使用僅僅安裝了 Docker 的機(jī)器作為實(shí)驗(yàn)環(huán)境。但是這里我會(huì)使用一個(gè)額外的包來簡化使用 cgroups:

$ sudo apt-get install cgroup-tools

首先,讓我們配置一個(gè)父 cgroup 條目。為了簡潔起見,我將僅使用 CPU 和內(nèi)存控制器

sudo cgcreate -g cpu,memory:/pod-foo


# Check if the corresponding folders were created:
ls -l /sys/fs/cgroup/cpu/pod-foo/
ls -l /sys/fs/cgroup/memory/pod-foo/

然后我們創(chuàng)建一個(gè)沙盒容器:

$ docker run -d --rm 
  --name foo_sandbox 
  --cgroup-parent /pod-foo 
  --ipc 'shareable' 
  alpine sleep infinity

最后,讓我們啟動(dòng)重用沙盒容器命名空間的實(shí)際容器:

# app (httpbin)
$ docker run -d --rm 
  --name app 
  --cgroup-parent /pod-foo 
  --network container:foo_sandbox 
  --ipc container:foo_sandbox 
  kennethreitz/httpbin


# sidecar (sleep)
$ docker run -d --rm 
  --name sidecar 
  --cgroup-parent /pod-foo 
  --network container:foo_sandbox 
  --ipc container:foo_sandbox 
  curlimages/curl sleep 365d

你注意到我省略了哪個(gè)命名空間嗎?沒錯(cuò),我不能在容器之間共享 uts 命名空間。似乎目前在 docker run 命令中沒法實(shí)現(xiàn)。嗯,是有點(diǎn)遺憾。但是除開 uts 命名空間之外,它是成功的!

cgroups 看上去很像 Kubernetes 創(chuàng)建的:

$ sudo systemd-cgls memory
Controller memory; Control group /:
├─pod-foo
│ ├─488d76cade5422b57ab59116f422d8483d435a8449ceda0c9a1888ea774acac7
│ │ ├─27865 /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
│ │ └─27880 /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
│ ├─9166a87f9a96a954b10ec012104366da9f1f6680387ef423ee197c61d37f39d7
│ │ └─27977 sleep 365d
│ └─c7b0ec46b16b52c5e1c447b77d67d44d16d78f9a3f93eaeb3a86aa95e08e28b6
│   └─27743 sleep infinity
···

全局命名空間列表看上去也很相似:

$ sudo lsns
        NS TYPE   NPROCS   PID USER    COMMAND
...
4026532157 mnt         1 27743 root    sleep infinity
4026532158 uts         1 27743 root    sleep infinity
4026532159 ipc         4 27743 root    sleep infinity
4026532160 pid         1 27743 root    sleep infinity
4026532162 net         4 27743 root    sleep infinity
4026532218 mnt         2 27865 root    /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
4026532219 uts         2 27865 root    /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
4026532220 pid         2 27865 root    /usr/bin/python3 /usr/local/bin/gunicorn -b 0.0.0.0:80 httpbin:app -k gevent
4026532221 mnt         1 27977 _apt    sleep 365d
4026532222 uts         1 27977 _apt    sleep 365d
4026532223 pid         1 27977 _apt    sleep 365d

httpbin 和 sidecar 容器看上去共享了 ipc 和 net 命名空間:

# app container
$ sudo ls -l /proc/27865/ns
lrwxrwxrwx 1 root root 0 Oct 28 07:56 ipc -> 'ipc:[4026532159]'
lrwxrwxrwx 1 root root 0 Oct 28 07:56 mnt -> 'mnt:[4026532218]'
lrwxrwxrwx 1 root root 0 Oct 28 07:56 net -> 'net:[4026532162]'
lrwxrwxrwx 1 root root 0 Oct 28 07:56 pid -> 'pid:[4026532220]'
lrwxrwxrwx 1 root root 0 Oct 28 07:56 uts -> 'uts:[4026532219]'


# sidecar container
$ sudo ls -l /proc/27977/ns
lrwxrwxrwx 1 _apt systemd-journal 0 Oct 28 07:56 ipc -> 'ipc:[4026532159]'
lrwxrwxrwx 1 _apt systemd-journal 0 Oct 28 07:56 mnt -> 'mnt:[4026532221]'
lrwxrwxrwx 1 _apt systemd-journal 0 Oct 28 07:56 net -> 'net:[4026532162]'
lrwxrwxrwx 1 _apt systemd-journal 0 Oct 28 07:56 pid -> 'pid:[4026532223]'
lrwxrwxrwx 1 _apt systemd-journal 0 Oct 28 07:56 uts -> 'uts:[4026532222]'

總結(jié)

Container 和 Pod 是相似的。在底層,它們主要依賴 Linux 命名空間和 cgroup。但是,Pod 不僅僅是一組容器。Pod 是一個(gè)自給自足的高級(jí)構(gòu)造。所有 Pod 的容器都運(yùn)行在同一臺(tái)機(jī)器(集群節(jié)點(diǎn))上,它們的生命周期是同步的,并且通過削弱隔離性來簡化容器間的通信。這使得 Pod 更接近于傳統(tǒng)的 VM,帶回了熟悉的部署模式,如 sidecar 或反向代理。






審核編輯:劉清

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請(qǐng)聯(lián)系本站處理。 舉報(bào)投訴
  • RAM
    RAM
    +關(guān)注

    關(guān)注

    8

    文章

    1369

    瀏覽量

    114880
  • Linux系統(tǒng)
    +關(guān)注

    關(guān)注

    4

    文章

    595

    瀏覽量

    27469
  • 虛擬機(jī)
    +關(guān)注

    關(guān)注

    1

    文章

    926

    瀏覽量

    28354
  • CRI
    CRI
    +關(guān)注

    關(guān)注

    1

    文章

    16

    瀏覽量

    12256
  • 內(nèi)存控制器
    +關(guān)注

    關(guān)注

    0

    文章

    40

    瀏覽量

    8913

原文標(biāo)題:解決你的困惑,K8S Pod與容器到底啥區(qū)別?

文章出處:【微信號(hào):magedu-Linux,微信公眾號(hào):馬哥Linux運(yùn)維】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。

收藏 人收藏

    評(píng)論

    相關(guān)推薦

    介紹如何安裝E1135C PDU和Pod升級(jí)

    Describes how to install the E1135C PDU and Pod upgrade.
    發(fā)表于 08-21 14:07

    從零開始入門 K8s| 詳解 Pod 及容器設(shè)計(jì)模式

    Docker 的時(shí)候,也沒有這個(gè)說法。其實(shí),如果想要理解 Pod,首先要理解容器,所以來回顧一下容器的概念:容器的本質(zhì)實(shí)際上是一個(gè)進(jìn)程,是一個(gè)視圖被隔離,資源受限的進(jìn)程。容器里面 PID=1 的進(jìn)程就是應(yīng)用本身
    發(fā)表于 09-20 15:12

    Pod資源配置

    《Kubernetes進(jìn)階實(shí)戰(zhàn)》第四章《管理Pod資源對(duì)象》
    發(fā)表于 10-22 14:39

    WiFi6:Pod in Per Room實(shí)現(xiàn)網(wǎng)絡(luò)全覆蓋

    ,WiFi6則不同,分布式WiFi及Pod in Per Room的設(shè)計(jì)將在最大程度上實(shí)現(xiàn)對(duì)于整個(gè)住宅的網(wǎng)絡(luò)覆蓋,具體的實(shí)現(xiàn)方法便是在每一個(gè)使用網(wǎng)絡(luò)的房間布置一個(gè)Pod
    的頭像 發(fā)表于 12-05 13:38 ?7197次閱讀

    Land Pattern and POD

    Land Pattern and POD
    發(fā)表于 03-05 15:59 ?0次下載
    Land Pattern and <b class='flag-5'>POD</b>

    Kubernetes組件pod核心原理

    1. 核心組件原理 —— pod 核心原理 1.1 pod 是什么 pod 也可以理解是一個(gè)容器,裝的是 docker 創(chuàng)建的容器,也就是用
    的頭像 發(fā)表于 09-02 09:27 ?1855次閱讀

    pod底層網(wǎng)絡(luò)和數(shù)據(jù)存儲(chǔ)是如何進(jìn)行的

    1. 核心組件原理 —— pod 核心原理 1.1 pod 是什么 pod 也可以理解是一個(gè)容器,裝的是 docker 創(chuàng)建的容器,也就是用
    的頭像 發(fā)表于 09-24 11:35 ?1713次閱讀

    Horizontal Pod Autoscaler的工作原理

    Horizontal Pod Autoscaler(HPA,Pod水平自動(dòng)伸縮),根據(jù)平均 CPU 利用率、平均內(nèi)存利用率或你指定的任何其他自定義指標(biāo)自動(dòng)調(diào)整 Deployment
    的頭像 發(fā)表于 09-21 10:57 ?1519次閱讀

    如何利用Docker實(shí)現(xiàn)Pod

    Container 和 Pod 是相似的。在底層,它們主要依賴 Linux 命名空間和 cgroup。但是,Pod 不僅僅是一組容器。Pod 是一個(gè)自給自足的高級(jí)構(gòu)造。
    發(fā)表于 11-14 12:51 ?1422次閱讀

    Kubernetes中的Pod簡易理解

    Pod是Kubernetes中非常重要的概念,也是Kubernetes管理的基本單位。正如其名,Pod像一個(gè)豌豆莢,可以容納多個(gè)container,擁有相同的IP地址。
    的頭像 發(fā)表于 02-15 10:44 ?1303次閱讀

    什么是CNI,基于Calico的Pod網(wǎng)絡(luò)介紹

    每一個(gè)Node上都會(huì)有一個(gè)tunl0的虛擬網(wǎng)卡,這個(gè)網(wǎng)卡可以理解成網(wǎng)橋,所有Pod都要基于此網(wǎng)橋來和其它Pod通信。 ② 每生成一個(gè)新的Pod,那么在Node上都會(huì)生成一個(gè)calixxxx的虛擬網(wǎng)卡,這個(gè)網(wǎng)卡會(huì)對(duì)應(yīng)到
    發(fā)表于 04-20 09:37 ?2399次閱讀

    k8s與pod之間是如何進(jìn)行網(wǎng)絡(luò)隔離的?

    NetworkPolicy用來控制PodPod之間的網(wǎng)絡(luò)通信,它也支持針對(duì)Namespace進(jìn)行限制。
    的頭像 發(fā)表于 05-11 09:35 ?1605次閱讀
    k8s與<b class='flag-5'>pod</b>之間是如何進(jìn)行網(wǎng)絡(luò)隔離的?

    iOS中Pod庫資源引用探究

    Cocoapods中Pod引用資源的方式有多種,不同的方式對(duì)資源的使用還是有區(qū)別的,但也有一定的規(guī)律,這里我用一個(gè)樣例工程來進(jìn)行說明,樣例工程名叫:AssetsDemo,使用pod lib create AssetsDemo命令創(chuàng)建
    的頭像 發(fā)表于 05-26 11:11 ?948次閱讀
    iOS中<b class='flag-5'>Pod</b>庫資源引用探究

    POD到底是什么?聊聊POD

    POD,即Plain Old Data的縮寫,plain代表普通,Old代表舊,從字面意思看是老的、普通的數(shù)據(jù)類型。
    的頭像 發(fā)表于 06-19 15:24 ?5681次閱讀

    Pod一直處于Pending狀態(tài)?什么是Pod拓?fù)浼s束?

    起因: 今天在部署組件的時(shí)候,發(fā)現(xiàn)組件的pod一直處于Pending狀態(tài),報(bào)錯(cuò)顯示的原因是:不滿足Pod拓?fù)浞植技s束,看了代碼發(fā)現(xiàn)是原來同事給組件新增了Pod拓?fù)浼s束。
    的頭像 發(fā)表于 12-18 11:46 ?1258次閱讀
    <b class='flag-5'>Pod</b>一直處于Pending狀態(tài)?什么是<b class='flag-5'>Pod</b>拓?fù)浼s束?
    主站蜘蛛池模板: 99热在线免费播放| 婷婷四房播客五月天| 男女啪啪久久精品亚洲A| 人人在线碰碰视频免费| 亚洲区欧美日韩综合| 办公室日本肉丝OL在线| 久久黄视频| 香蕉eeww99国产精品| YELLOW日本动漫免费动漫| 久久久精品免费免费直播| 无限资源在线观看完整版免费下载| 4455永久在线毛片观看| 国内精品久久影视免费| 日日夜夜撸 在线影院| 97超视频在线观看| 久久国产综合精品欧美| 亚洲国产日韩欧美在线a乱码| couo福利姬图库| 久久人妻无码毛片A片麻豆| 性奴公司 警花| 国产精品成人A蜜柚在线观看| 秋霞鲁丝片Av无码| 97伦理电影在线不卡| 久久久久国产精品嫩草影院| 亚洲精品成人| 国产人成精品综合欧美成人| 色噜噜视频| 超碰在线线公开免费视频| 暖暖 日本 视频 在线观看免费 | 恋老视频 国产国佬| 亚洲无码小格式| 含羞草完整视频在线播放免费| 我强进了老师身体在线观看 | 人妻插B视频一区二区三区| 99精品视频免费观看| 狂操空姐电影| 最好看中文字幕国语| 久久综合狠狠综合狠狠| 在线播放性xxx欧美| 久久麻豆国产国产AV| 永久精品免费影院在线观看网站|