Разница между docker привилегированным режимом и контейнером привилегий kubernetes

Question

Какая разница в привилегиях, предоставленных контейнеру в следующих 2 сценариях ios

1. sudo docker run -d --privileged --pid = host alpine: 3.8 tail - f / dev / null
2. Использование kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: nsenter-alpine
spec:
  hostPID: true
  containers:
    - name: nsenter-alpine
      image: alpine:3.8
      resources:
        limits:
          cpu: "500m"
          memory: "200Mi"
        requests:
          cpu: "100m"
          memory: "100Mi"
      command: ["tail"]
      args: ["-f", "/dev/null"]
      securityContext:
        privilege: true

в случае 1)

/ # ps -ef | wc -l
604

в случае 2)

[root@localhost /]# ps -ef | wc -l
266

Очевидно, что когда контейнер привилегий создается непосредственно с использованием docker, он может видеть процессы хоста, но когда он запускается с использованием kubernetes, он может видеть только несколько процессов. В чем причина этого?

Answer 1

Редактировать:

Я вижу, у вас есть --pid=host в docker run команде и hostPID: true в kubernetes pod spe c. В этом случае оба числа должны быть одинаковыми, если контейнеры работают на одном хосте. Проверьте, работают ли контейнеры на одном хосте или нет. Kubernetes, возможно, запланировал модуль к другому узлу.

---

Предыдущий ответ

sudo docker run -d --privileged --pid=host alpine:3.8 tail -f /dev/null

В приведенной выше команде вы используете аргумент --pid=host который выполняет контейнер в пространстве имен хоста pid. Таким образом, вы можете просматривать все процессы на хосте. То же самое можно сделать с помощью опции hostPID в pod spe c в kubernetes.

---

Запуск контейнера в привилегированном режиме означает, что процессы в контейнере по существу равны root на хосте. По умолчанию контейнеру не разрешен доступ к каким-либо устройствам на хосте, но «привилегированному» контейнеру предоставляется доступ ко всем устройствам на хосте.

$ kubectl exec -it no-privilege ls /dev
core             null             stderr           urandom
fd               ptmx             stdin            zero
full             pts              stdout
fuse             random           termination-log
mqueue           shm              tty

$ kubectl exec -it privileged ls /dev
autofs              snd                 tty46
bsg                 sr0                 tty47
btrfs-control       stderr              tty48
core                stdin               tty49
cpu                 stdout              tty5
cpu_dma_latency     termination-log     tty50
fd                  tty                 tty51
full                tty0                tty52
fuse                tty1                tty53
hpet                tty10               tty54
hwrng               tty11               tty55
...

Контейнер по-прежнему работает в своем собственном пространстве имен pid, ip c и сетевом пространстве имен et c. Таким образом, вы не увидите хост-процессы внутри контейнера даже при работе в привилегированном режиме. Вы можете использовать hostPID, hostNetwork, hostIPC поля pod spe c в Kubernetes, если вы хотите работать в пространстве имен хоста.