[Перевод] Как работает kubectl exec?22.10.2019 10:03

Прим. перев.: автор статьи — Erkan Erol, инженер из SAP — делится своим изучением механизмов функционирования команды kubectl exec, столь привычной для всех, кто работает с Kubernetes. Весь алгоритм он сопровождает листингами исходного кода Kubernetes (и связанных проектов), которые позволяют разобраться в теме настолько глубоко, насколько это требуется.

В одну из пятниц ко мне подошел коллега и поинтересовался, как выполнить команду в pod’е с помощью client-go. Я не смог ему ответить и внезапно осознал, что ничего не знаю о механизме работы kubectl exec. Да, у меня были определенные представления о его устройстве, однако я не был уверен на 100% в их правильности и потому решил заняться этим вопросом. Проштудировав блоги, документацию и исходный код, узнал много нового, и в этой статье хочу поделиться своими открытиями и пониманием. Если что-то не так, пожалуйста, свяжитесь со мной в Twitter.

Подготовка

Чтобы создать кластер на MacBook’е, я склонировал ecomm-integration-ballerina/kubernetes-cluster. Затем поправил IP-адреса узлов в конфиге kubelet«а, поскольку настройки по умолчанию не позволяли выполнять kubectl exec. Подробнее об основной причине тому можно прочитать здесь.

Любая машина = мой MacBook
IP master-узла = 192.168.205.10
IP worker-узла = 192.168.205.11
порт API-сервера = 6443

Компоненты

kubectl exec process: когда мы выполняем «kubectl exec…», запускается процесс. Делать это можно на любой машине с доступом к API-серверу K8s. Прим. перев.: Далее в консольных листингах автор использует комментарий «any machine», подразумевая, что последующие команды можно выполнять на любых таких машинах с доступом к Kubernetes.
api server: компонент на мастер-узле, предоставляющий доступ к API Kubernetes. Это фронтенд для control plane в Kubernetes.
kubelet: агент, который работает на каждом узле в кластере. Он обеспечивает работу контейнеров в pod’е.
container runtime (исполняемая среда контейнера): программное обеспечение, отвечающее за работу контейнеров. Примеры: Docker, CRI-O, containerd…
kernel: ядро ОС на рабочем узле; отвечает за управление процессами.
target (целевой) container: контейнер, являющийся частью pod’а и функционирующий на одном из рабочих узлов.

Что я обнаружил

1. Активность на стороне клиента

Создаем pod в пространстве имен default:

// any machine
$ kubectl run exec-test-nginx --image=nginx

Затем выполняем команду exec и ждем 5000 секунд для дальнейших наблюдений:

// any machine
$ kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- sh
# sleep 5000

Появляется процесс kubectl (с pid=8507 в нашем случае):

// any machine
$ ps -ef |grep kubectl
501  8507  8409   0  7:19PM ttys000    0:00.13 kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- sh

Если проверить сетевую активность процесса, мы обнаружим, что у него есть подключения к api-server’у (192.168.205.10.6443):

// any machine
$ netstat -atnv |grep 8507
tcp4       0      0  192.168.205.1.51673    192.168.205.10.6443    ESTABLISHED 131072 131768   8507      0 0x0102 0x00000020
tcp4       0      0  192.168.205.1.51672    192.168.205.10.6443    ESTABLISHED 131072 131768   8507      0 0x0102 0x00000028

Давайте посмотрим на код. Kubectl создает POST-запрос с субресурсом exec и посылает REST-запрос:

              req := restClient.Post().
                        Resource("pods").
                        Name(pod.Name).
                        Namespace(pod.Namespace).
                        SubResource("exec")
                req.VersionedParams(&corev1.PodExecOptions{
                        Container: containerName,
                        Command:   p.Command,
                        Stdin:     p.Stdin,
                        Stdout:    p.Out != nil,
                        Stderr:    p.ErrOut != nil,
                        TTY:       t.Raw,
                }, scheme.ParameterCodec)

                return p.Executor.Execute("POST", req.URL(), p.Config, p.In, p.Out, p.ErrOut, t.Raw, sizeQueue)

(kubectl/pkg/cmd/exec/exec.go)

2. Активность на стороне мастер-узла

Мы также можем наблюдать запрос на стороне api-server’а:

handler.go:143] kube-apiserver: POST "/api/v1/namespaces/default/pods/exec-test-nginx-6558988d5-fgxgg/exec" satisfied by gorestful with webservice /api/v1
upgradeaware.go:261] Connecting to backend proxy (intercepting redirects) https://192.168.205.11:10250/exec/default/exec-test-nginx-6558988d5-fgxgg/exec-test-nginx?command=sh&input=1&output=1&tty=1
Headers: map[Connection:[Upgrade] Content-Length:[0] Upgrade:[SPDY/3.1] User-Agent:[kubectl/v1.12.10 (darwin/amd64) kubernetes/e3c1340] X-Forwarded-For:[192.168.205.1] X-Stream-Protocol-Version:[v4.channel.k8s.io v3.channel.k8s.io v2.channel.k8s.io channel.k8s.io]]

Обратите внимание, что HTTP-запрос включает запрос на изменение протокола. SPDY позволяет мультиплексировать отдельные «потоки» stdin/stdout/stderr/spdy-error через единое TCP-соединение.

API-сервер получает запрос и преобразует его в PodExecOptions:

// PodExecOptions is the query options to a Pod's remote exec call
type PodExecOptions struct {
        metav1.TypeMeta

        // Stdin if true indicates that stdin is to be redirected for the exec call
        Stdin bool

        // Stdout if true indicates that stdout is to be redirected for the exec call
        Stdout bool

        // Stderr if true indicates that stderr is to be redirected for the exec call
        Stderr bool

        // TTY if true indicates that a tty will be allocated for the exec call
        TTY bool

        // Container in which to execute the command.
        Container string

        // Command is the remote command to execute; argv array; not executed within a shell.
        Command []string
}

(pkg/apis/core/types.go)

Чтобы выполнить требуемые действия, api-server должен знать, с каким pod’ом ему необходимо связаться:

// ExecLocation returns the exec URL for a pod container. If opts.Container is blank
// and only one container is present in the pod, that container is used.
func ExecLocation(
        getter ResourceGetter,
        connInfo client.ConnectionInfoGetter,
        ctx context.Context,
        name string,
        opts *api.PodExecOptions,
) (*url.URL, http.RoundTripper, error) {
        return streamLocation(getter, connInfo, ctx, name, opts, opts.Container, "exec")
}

(pkg/registry/core/pod/strategy.go)

Конечно, данные об endpoint’е берутся из информации об узле:

        nodeName := types.NodeName(pod.Spec.NodeName)
        if len(nodeName) == 0 {
                // If pod has not been assigned a host, return an empty location
                return nil, nil, errors.NewBadRequest(fmt.Sprintf("pod %s does not have a host assigned", name))
        }
        nodeInfo, err := connInfo.GetConnectionInfo(ctx, nodeName)

(pkg/registry/core/pod/strategy.go)

Ура! У kubelet’а теперь есть порт (node.Status.DaemonEndpoints.KubeletEndpoint.Port), к которому может подключиться API-сервер:

// GetConnectionInfo retrieves connection info from the status of a Node API object.
func (k *NodeConnectionInfoGetter) GetConnectionInfo(ctx context.Context, nodeName types.NodeName) (*ConnectionInfo, error) {
        node, err := k.nodes.Get(ctx, string(nodeName), metav1.GetOptions{})
        if err != nil {
                return nil, err
        }

        // Find a kubelet-reported address, using preferred address type
        host, err := nodeutil.GetPreferredNodeAddress(node, k.preferredAddressTypes)
        if err != nil {
                return nil, err
        }

        // Use the kubelet-reported port, if present
        port := int(node.Status.DaemonEndpoints.KubeletEndpoint.Port)
        if port <= 0 {
                port = k.defaultPort
        }

        return &ConnectionInfo{
                Scheme:    k.scheme,
                Hostname:  host,
                Port:      strconv.Itoa(port),
                Transport: k.transport,
        }, nil
}

(pkg/kubelet/client/kubelet_client.go)

Из документации Master-Node Communication > Master to Cluster > apiserver to kubelet:
Эти подключения замыкаются на HTTPS endpoint’е kubelet’а. По умолчанию, apiserver не проверяет сертификат kubelet’а, что делает соединение уязвимым к «атакам посредника» (MITM) и небезопасным для работы в ненадежных и/или публичных сетях.

Теперь API-сервер знает endpoint и устанавливает соединение:

// Connect returns a handler for the pod exec proxy
func (r *ExecREST) Connect(ctx context.Context, name string, opts runtime.Object, responder rest.Responder) (http.Handler, error) {
        execOpts, ok := opts.(*api.PodExecOptions)
        if !ok {
                return nil, fmt.Errorf("invalid options object: %#v", opts)
        }
        location, transport, err := pod.ExecLocation(r.Store, r.KubeletConn, ctx, name, execOpts)
        if err != nil {
                return nil, err
        }
        return newThrottledUpgradeAwareProxyHandler(location, transport, false, true, true, responder), nil
}

(pkg/registry/core/pod/rest/subresources.go)

Давайте посмотрим, что происходит на мастер-узле.

Сначала узнаем IP рабочего узла. В нашем случае это 192.168.205.11:

// any machine
$ kubectl get nodes k8s-node-1 -o wide
NAME         STATUS   ROLES    AGE   VERSION   INTERNAL-IP      EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
k8s-node-1   Ready       9h    v1.15.3   192.168.205.11           Ubuntu 16.04.6 LTS   4.4.0-159-generic   docker://17.3.3

Затем установим порт kubelet’а (10250 в нашем случае):

// any machine
$ kubectl get nodes k8s-node-1 -o jsonpath='{.status.daemonEndpoints.kubeletEndpoint}'
map[Port:10250]

Теперь пора проверить сеть. Есть ли подключение к рабочему узлу (192.168.205.11)? Оно есть! Если «убить» процесс exec, оно исчезнет, поэтому я знаю, что подключение установлено api-server’ом как следствие выполненной exec-команды.

// master node
$ netstat -atn |grep 192.168.205.11
tcp        0      0 192.168.205.10:37870    192.168.205.11:10250    ESTABLISHED
…

Соединение между kubectl’ом и api-server’ом по-прежнему открыто. Кроме того, есть еще одно соединение, связывающее api-server и kubelet.

3. Активность на рабочем узле

Теперь давайте подключимся к worker-узлу и посмотрим, что происходит на нем.

Прежде всего мы видим, что соединение с ним также установлено (вторая строка); 192.168.205.10 — это IP master-узла:

 // worker node
  $ netstat -atn |grep 10250
  tcp6       0      0 :::10250                :::*                    LISTEN
  tcp6       0      0 192.168.205.11:10250    192.168.205.10:37870    ESTABLISHED

А как насчет нашей команды sleep? Ура, она тоже присутствует!

 // worker node
  $ ps -afx
  ...
  31463 ?        Sl     0:00      \_ docker-containerd-shim 7d974065bbb3107074ce31c51f5ef40aea8dcd535ae11a7b8f2dd180b8ed583a /var/run/docker/libcontainerd/7d974065bbb3107074ce31c51
  31478 pts/0    Ss     0:00          \_ sh
  31485 pts/0    S+     0:00              \_ sleep 5000
  …

Но постойте: как kubelet провернул это? В kubelet есть демон, который открывает доступ к API через порт для запросов api-server’а:

// Server is the library interface to serve the stream requests.
type Server interface {
        http.Handler

        // Get the serving URL for the requests.
        // Requests must not be nil. Responses may be nil iff an error is returned.
        GetExec(*runtimeapi.ExecRequest) (*runtimeapi.ExecResponse, error)
        GetAttach(req *runtimeapi.AttachRequest) (*runtimeapi.AttachResponse, error)
        GetPortForward(*runtimeapi.PortForwardRequest) (*runtimeapi.PortForwardResponse, error)

        // Start the server.
        // addr is the address to serve on (address:port) stayUp indicates whether the server should
        // listen until Stop() is called, or automatically stop after all expected connections are
        // closed. Calling Get{Exec,Attach,PortForward} increments the expected connection count.
        // Function does not return until the server is stopped.
        Start(stayUp bool) error
        // Stop the server, and terminate any open connections.
        Stop() error
}

(pkg/kubelet/server/streaming/server.go)

Kubelet вычисляет ответный endpoint для exec-запросов:

func (s *server) GetExec(req *runtimeapi.ExecRequest) (*runtimeapi.ExecResponse, error) {
        if err := validateExecRequest(req); err != nil {
                return nil, err
        }
        token, err := s.cache.Insert(req)
        if err != nil {
                return nil, err
        }
        return &runtimeapi.ExecResponse{
                Url: s.buildURL("exec", token),
        }, nil
}

(pkg/kubelet/server/streaming/server.go)

Не перепутайте. Он возвращает не результат команды, а endpoint для связи:

type ExecResponse struct {
        // Fully qualified URL of the exec streaming server.
        Url                  string   `protobuf:"bytes,1,opt,name=url,proto3" json:"url,omitempty"`
        XXX_NoUnkeyedLiteral struct{} `json:"-"`
        XXX_sizecache        int32    `json:"-"`
}