Hinweis.: Der Autor des Artikels — Erkan Erol, Ingenieur bei SAP — teilt sein Wissen über die Funktionsweise des Teams kubectl exec, das jedem, der mit Kubernetes arbeitet, so vertraut ist. Der gesamte Algorithmus wird durch Listing des Quellcodes von Kubernetes (und verwandten Projekten) begleitet, die es ermöglichen, das Thema so tief zu verstehen, wie es erforderlich ist.
An einem Freitag kam ein Kollege zu mir und fragte, wie man einen Befehl in einem Pod mit Hilfe von ausführt. Ich konnte ihm keine Antwort geben und erkannte plötzlich, dass ich nichts über die Arbeitsweise von kubectl execwusste. Ja, ich hatte bestimmte Vorstellungen über seine Struktur, jedoch war ich mir nicht 100% sicher, ob sie korrekt waren, und beschloss, mich mit diesem Thema zu befassen. Nachdem ich Blogs, Dokumentationen und den Quellcode durchforstet hatte, erfuhr ich viel Neues und möchte in diesem Artikel meine Entdeckungen und mein Verständnis teilen. Wenn etwas nicht stimmt, bitte kontaktieren Sie mich unter .
Vorbereitung
Um einen Cluster auf einem MacBook zu erstellen, habe ich kloniert. Dann habe ich die IP-Adressen der Knoten in der kubelet-Konfiguration geändert, da die Standardeinstellungen es nicht erlaubten, kubectl exec. Weitere Informationen über den Hauptgrund dafür können gelesen werden .
- Jede Maschine = mein MacBook
- IP Master-Knoten = 192.168.205.10
- IP Worker-Knoten = 192.168.205.11
- API-Server-Port = 6443
Komponenten
- kubectl exec Prozess: Wenn wir 'kubectl exec …' ausführen, wird ein Prozess gestartet. Dies kann auf jeder Maschine mit Zugang zum K8s API-Server erfolgen. Anm. d. Üb.: In den folgenden Konsolen-Listings verwendet der Autor den Kommentar 'any machine', was bedeutet, dass die nachfolgenden Befehle auf beliebigen Maschinen mit Zugang zu Kubernetes ausgeführt werden können.
- : Ein Bestandteil des Master-Knotens, der den Zugang zur Kubernetes API bereitstellt. Dies ist das Frontend für den Control Plane in Kubernetes.
- : Ein Agent, der auf jedem Knoten im Cluster läuft. Er stellt die Ausführung von Containern im Pod sicher.
- (Ausführungsumgebung für Container): Software, die für die Ausführung von Containern verantwortlich ist. Beispiele: Docker, CRI-O, containerd…
- Kernel: Das Betriebssystem-Kernel auf dem Worker-Knoten; verantwortlich für das Management von Prozessen.
- target (Ziel) container: Ein Container, der Teil eines Pods ist und auf einem der Worker-Knoten funktioniert.
Was ich festgestellt habe
1. Aktivität auf der Client-Seite
Erstellen eines Pods im Namensraum default:
// any machine
$ kubectl run exec-test-nginx --image=nginxDann führen wir den Exec-Befehl aus und warten 5000 Sekunden für weitere Beobachtungen:
// any machine
$ kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- sh
# sleep 5000Der kubectl-Prozess erscheint (mit pid=8507 in unserem Fall):
// any machine
$ ps -ef |grep kubectl
501 8507 8409 0 7:19PM ttys000 0:00.13 kubectl exec -it exec-test-nginx-6558988d5-fgxgg -- shWenn wir die Netzwerkaktivität des Prozesses überprüfen, stellen wir fest, dass es Verbindungen zum API-Server (192.168.205.10:6443) gibt:
// 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 0x00000028Schauen wir uns den Code an. Kubectl erstellt eine POST-Anfrage mit der Subressource exec und sendet die REST-Anfrage:
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)()
2. Aktivität auf der Master-Node-Seite
Wir können auch die Anfrage auf der Seite des API-Servers beobachten:
handler.go:143] kube-apiserver: POST "/api/v1/namespaces/default/pods/exec-test-nginx-6558988d5-fgxgg/exec" wurde von gorestful mit dem Webservice /api/v1 erfüllt
upgradeaware.go:261] Verbindung zum Backend-Proxy (Umleitungen abfangen) https://192.168.205.11:10250/exec/default/exec-test-nginx-6558988d5-fgxgg/exec-test-nginx?command=sh&input=1&output=1&tty=1
Header: 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]]Bitte beachten Sie, dass die HTTP-Anfrage eine Anfrage zur Protokolländerung umfasst. ermöglicht die Multiplexierung einzelner Streams stdin/stdout/stderr/spdy-error über eine einzige TCP-Verbindung.
Der API-Server erhält die Anfrage und wandelt sie um in 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
}()
Um die erforderlichen Aktionen auszuführen, muss der API-Server wissen, mit welchem Pod er kommunizieren muss:
// 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")
}()
Natürlich stammen die Daten über den Endpoint aus den Informationen über den Knoten:
nodeName := types.NodeName(pod.Spec.NodeName)
if len(nodeName) == 0 {
// Wenn der Pod keinem Host zugewiesen wurde, geben Sie einen leeren Standort zurück
return nil, nil, errors.NewBadRequest(fmt.Sprintf("Pod %s hat keinen Host zugewiesen", name))
}
nodeInfo, err := connInfo.GetConnectionInfo(ctx, nodeName)()
Hurra! Der Kubelet hat jetzt einen Port (node.Status.DaemonEndpoints.KubeletEndpoint.Port), an den sich der API-Server anschließen kann:
// 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
}()
Aus der Dokumentation :
Diese Verbindungen werden an den HTTPS-Endpoint des Kubelet gebunden. Standardmäßig überprüft der Apiserver das Zertifikat des Kubelet nicht, was die Verbindung anfällig für "Man-in-the-Middle"-Angriffe (MITM) macht und und unsicheren für den Betrieb in unsicheren und/oder öffentlichen Netzwerken.
Jetzt kennt der API-Server den Endpoint und stellt die Verbindung her:
// 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
}()
Lassen Sie uns sehen, was auf dem Master-Knoten passiert.
Zuerst erfahren wir die IP des Worker-Knotens. In unserem Fall ist das 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 <none> 9h v1.15.3 192.168.205.11 <none> Ubuntu 16.04.6 LTS 4.4.0-159-generic docker://17.3.3Dann stellen wir den Port des Kubelets ein (10250 in unserem Fall):
// any machine
$ kubectl get nodes k8s-node-1 -o jsonpath='{.status.daemonEndpoints.kubeletEndpoint}'
map[Port:10250] Jetzt ist es Zeit, das Netzwerk zu überprüfen. Gibt es eine Verbindung zum Worker-Knoten (192.168.205.11)? Ja, das gibt es! Wenn der Prozess "getötet" wird, exec, wird es verschwinden, daher weiß ich, dass die Verbindung vom API-Server als Folge des ausgeführten Exec-Befehls hergestellt wurde.
// master node
$ netstat -atn |grep 192.168.205.11
tcp 0 0 192.168.205.10:37870 192.168.205.11:10250 ESTABLISHED
… 
Die Verbindung zwischen kubectl und dem API-Server ist nach wie vor geöffnet. Darüber hinaus gibt es eine weitere Verbindung, die API-Server und Kubelet verbindet.
3. Aktivität auf dem Worker-Knoten
Jetzt lassen Sie uns mit dem Worker-Knoten verbinden und sehen, was dort passiert.
Zunächst sehen wir, dass auch eine Verbindung zu ihm hergestellt wurde (zweite Zeile); 192.168.205.10 ist die IP des Master-Knotens:
// 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 Wie steht es um unser Kommando 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
…Aber warten Sie: Wie hat kubelet das gemacht? Im Kubelet gibt es einen Daemon, der den Zugriff auf die API über einen Port für Anfragen des API-Servers öffnet:
// 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
}()
Kubelet berechnet den Rückgabe-Endpunkt für Exec-Anfragen:
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
}()
Verwechseln Sie es nicht. Es gibt nicht das Ergebnis des Befehls zurück, sondern den Endpunkt für die Kommunikation:
type ExecResponse struct {
// Vollständig qualifizierte URL des Exec-Streaming-Servers.
Url string `protobuf:"bytes,1,opt,name=url,proto3" json:"url,omitempty"`
XXX_NoUnkeyedLiteral struct{} `json:"-"`
XXX_sizecache int32 `json:"-"`
}()
Kubelet implementiert das Interface RuntimeServiceClient, das Teil des Container Runtime Interface ist (mehr darüber haben wir zum Beispiel geschrieben, — Anmerkung des Übersetzers).:
Lange Auflistung aus cri-api in kubernetes/kubernetes
// For semantics around ctx use and closing/ending streaming RPCs, please refer to https://godoc.org/google.golang.org/grpc#ClientConn.NewStream.
type RuntimeServiceClient interface {
// Version returns the runtime name, runtime version, and runtime API version.
Version(ctx context.Context, in *VersionRequest, opts ...grpc.CallOption) (*VersionResponse, error)
// RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure
// the sandbox is in the ready state on success.
RunPodSandbox(ctx context.Context, in *RunPodSandboxRequest, opts ...grpc.CallOption) (*RunPodSandboxResponse, error)
// StopPodSandbox stops any running process that is part of the sandbox and
// reclaims network resources (e.g., IP addresses) allocated to the sandbox.
// If there are any running containers in the sandbox, they must be forcibly
// terminated.
// This call is idempotent, and must not return an error if all relevant
// resources have already been reclaimed. kubelet will call StopPodSandbox
// at least once before calling RemovePodSandbox. It will also attempt to
// reclaim resources eagerly, as soon as a sandbox is not needed. Hence,
// multiple StopPodSandbox calls are expected.
StopPodSandbox(ctx context.Context, in *StopPodSandboxRequest, opts ...grpc.CallOption) (*StopPodSandboxResponse, error)
// RemovePodSandbox removes the sandbox. If there are any running containers
// in the sandbox, they must be forcibly terminated and removed.
// This call is idempotent, and must not return an error if the sandbox has
// already been removed.
RemovePodSandbox(ctx context.Context, in *RemovePodSandboxRequest, opts ...grpc.CallOption) (*RemovePodSandboxResponse, error)
// PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not
// present, returns an error.
PodSandboxStatus(ctx context.Context, in *PodSandboxStatusRequest, opts ...grpc.CallOption) (*PodSandboxStatusResponse, error)
// ListPodSandbox returns a list of PodSandboxes.
ListPodSandbox(ctx context.Context, in *ListPodSandboxRequest, opts ...grpc.CallOption) (*ListPodSandboxResponse, error)
// CreateContainer creates a new container in specified PodSandbox
CreateContainer(ctx context.Context, in *CreateContainerRequest, opts ...grpc.CallOption) (*CreateContainerResponse, error)
// StartContainer starts the container.
StartContainer(ctx context.Context, in *StartContainerRequest, opts ...grpc.CallOption) (*StartContainerResponse, error)
// StopContainer stops a running container with a grace period (i.e., timeout).
// This call is idempotent, and must not return an error if the container has
// already been stopped.
// TODO: what must the runtime do after the grace period is reached?
StopContainer(ctx context.Context, in *StopContainerRequest, opts ...grpc.CallOption) (*StopContainerResponse, error)
// RemoveContainer removes the container. If the container is running, the
// container must be forcibly removed.
// This call is idempotent, and must not return an error if the container has
// already been removed.
RemoveContainer(ctx context.Context, in *RemoveContainerRequest, opts ...grpc.CallOption) (*RemoveContainerResponse, error)
// ListContainers lists all containers by filters.
ListContainers(ctx context.Context, in *ListContainersRequest, opts ...grpc.CallOption) (*ListContainersResponse, error)
// ContainerStatus returns status of the container. If the container is not
// present, returns an error.
ContainerStatus(ctx context.Context, in *ContainerStatusRequest, opts ...grpc.CallOption) (*ContainerStatusResponse, error)
// UpdateContainerResources updates ContainerConfig of the container.
UpdateContainerResources(ctx context.Context, in *UpdateContainerResourcesRequest, opts ...grpc.CallOption) (*UpdateContainerResourcesResponse, error)
// ReopenContainerLog asks runtime to reopen the stdout/stderr log file
// for the container. This is often called after the log file has been
// rotated. If the container is not running, container runtime can choose
// to either create a new log file and return nil, or return an error.
// Once it returns error, new container log file MUST NOT be created.
ReopenContainerLog(ctx context.Context, in *ReopenContainerLogRequest, opts ...grpc.CallOption) (*ReopenContainerLogResponse, error)
// ExecSync runs a command in a container synchronously.
ExecSync(ctx context.Context, in *ExecSyncRequest, opts ...grpc.CallOption) (*ExecSyncResponse, error)
// Exec prepares a streaming endpoint to execute a command in the container.
Exec(ctx context.Context, in *ExecRequest, opts ...grpc.CallOption) (*ExecResponse, error)
// Attach prepares a streaming endpoint to attach to a running container.
Attach(ctx context.Context, in *AttachRequest, opts ...grpc.CallOption) (*AttachResponse, error)
// PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
PortForward(ctx context.Context, in *PortForwardRequest, opts ...grpc.CallOption) (*PortForwardResponse, error)
// ContainerStats returns stats of the container. If the container does not
// exist, the call returns an error.
ContainerStats(ctx context.Context, in *ContainerStatsRequest, opts ...grpc.CallOption) (*ContainerStatsResponse, error)
// ListContainerStats returns stats of all running containers.
ListContainerStats(ctx context.Context, in *ListContainerStatsRequest, opts ...grpc.CallOption) (*ListContainerStatsResponse, error)
// UpdateRuntimeConfig updates the runtime configuration based on the given request.
UpdateRuntimeConfig(ctx context.Context, in *UpdateRuntimeConfigRequest, opts ...grpc.CallOption) (*UpdateRuntimeConfigResponse, error)
// Status returns the status of the runtime.
Status(ctx context.Context, in *StatusRequest, opts ...grpc.CallOption) (*StatusResponse, error)
} ()
Es nutzt einfach gRPC, um die Methode über das Container Runtime Interface aufzurufen:
type runtimeServiceClient struct {
cc *grpc.ClientConn
}()
func (c *runtimeServiceClient) Exec(ctx context.Context, in *ExecRequest, opts ...grpc.CallOption) (*ExecResponse, error) {
out := new(ExecResponse)
err := c.cc.Invoke(ctx, "/runtime.v1alpha2.RuntimeService/Exec", in, out, opts...)
if err != nil {
return nil, err
}
return out, nil
}()
Container Runtime ist für die Implementierung verantwortlich RuntimeServiceServer:
Lange Auflistung aus cri-api in kubernetes/kubernetes
// RuntimeServiceServer is the server API for RuntimeService service.
type RuntimeServiceServer interface {
// Version returns the runtime name, runtime version, and runtime API version.
Version(context.Context, *VersionRequest) (*VersionResponse, error)
// RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure
// the sandbox is in the ready state on success.
RunPodSandbox(context.Context, *RunPodSandboxRequest) (*RunPodSandboxResponse, error)
// StopPodSandbox stops any running process that is part of the sandbox and
// reclaims network resources (e.g., IP addresses) allocated to the sandbox.
// If there are any running containers in the sandbox, they must be forcibly
// terminated.
// This call is idempotent, and must not return an error if all relevant
// resources have already been reclaimed. kubelet will call StopPodSandbox
// at least once before calling RemovePodSandbox. It will also attempt to
// reclaim resources eagerly, as soon as a sandbox is not needed. Hence,
// multiple StopPodSandbox calls are expected.
StopPodSandbox(context.Context, *StopPodSandboxRequest) (*StopPodSandboxResponse, error)
// RemovePodSandbox removes the sandbox. If there are any running containers
// in the sandbox, they must be forcibly terminated and removed.
// This call is idempotent, and must not return an error if the sandbox has
// already been removed.
RemovePodSandbox(context.Context, *RemovePodSandboxRequest) (*RemovePodSandboxResponse, error)
// PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not
// present, returns an error.
PodSandboxStatus(context.Context, *PodSandboxStatusRequest) (*PodSandboxStatusResponse, error)
// ListPodSandbox returns a list of PodSandboxes.
ListPodSandbox(context.Context, *ListPodSandboxRequest) (*ListPodSandboxResponse, error)
// CreateContainer creates a new container in specified PodSandbox
CreateContainer(context.Context, *CreateContainerRequest) (*CreateContainerResponse, error)
// StartContainer starts the container.
StartContainer(context.Context, *StartContainerRequest) (*StartContainerResponse, error)
// StopContainer stops a running container with a grace period (i.e., timeout).
// This call is idempotent, and must not return an error if the container has
// already been stopped.
// TODO: what must the runtime do after the grace period is reached?
StopContainer(context.Context, *StopContainerRequest) (*StopContainerResponse, error)
// RemoveContainer removes the container. If the container is running, the
// container must be forcibly removed.
// This call is idempotent, and must not return an error if the container has
// already been removed.
RemoveContainer(context.Context, *RemoveContainerRequest) (*RemoveContainerResponse, error)
// ListContainers lists all containers by filters.
ListContainers(context.Context, *ListContainersRequest) (*ListContainersResponse, error)
// ContainerStatus returns status of the container. If the container is not
// present, returns an error.
ContainerStatus(context.Context, *ContainerStatusRequest) (*ContainerStatusResponse, error)
// UpdateContainerResources updates ContainerConfig of the container.
UpdateContainerResources(context.Context, *UpdateContainerResourcesRequest) (*UpdateContainerResourcesResponse, error)
// ReopenContainerLog asks runtime to reopen the stdout/stderr log file
// for the container. This is often called after the log file has been
// rotated. If the container is not running, container runtime can choose
// to either create a new log file and return nil, or return an error.
// Once it returns error, new container log file MUST NOT be created.
ReopenContainerLog(context.Context, *ReopenContainerLogRequest) (*ReopenContainerLogResponse, error)
// ExecSync runs a command in a container synchronously.
ExecSync(context.Context, *ExecSyncRequest) (*ExecSyncResponse, error)
// Exec prepares a streaming endpoint to execute a command in the container.
Exec(context.Context, *ExecRequest) (*ExecResponse, error)
// Attach prepares a streaming endpoint to attach to a running container.
Attach(context.Context, *AttachRequest) (*AttachResponse, error)
// PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
PortForward(context.Context, *PortForwardRequest) (*PortForwardResponse, error)
// ContainerStats returns stats of the container. If the container does not
// exist, the call returns an error.
ContainerStats(context.Context, *ContainerStatsRequest) (*ContainerStatsResponse, error)
// ListContainerStats returns stats of all running containers.
ListContainerStats(context.Context, *ListContainerStatsRequest) (*ListContainerStatsResponse, error)
// UpdateRuntimeConfig updates the runtime configuration based on the given request.
UpdateRuntimeConfig(context.Context, *UpdateRuntimeConfigRequest) (*UpdateRuntimeConfigResponse, error)
// Status returns the status of the runtime.
Status(context.Context, *StatusRequest) (*StatusResponse, error)
} ()
Wenn dem so ist, sollten wir die Verbindung zwischen dem Kubelet und der Container-Ausführungsumgebung sehen, richtig? Lassen Sie uns das überprüfen.
Führen Sie diesen Befehl vor und nach dem exec-Befehl aus und beobachten Sie die Unterschiede. In meinem Fall ist der Unterschied wie folgt:
// worker node
$ ss -a -p |grep kubelet
...
u_str ESTAB 0 0 * 157937 * 157387 users:(("kubelet",pid=5714,fd=33))
...Hmm… Neue Verbindung über Unix-Sockets zwischen dem Kubelet (pid=5714) und etwas Unbekanntem. Was könnte das sein? Richtig, das ist Docker (pid=1186)!
// worker node
$ ss -a -p |grep 157387
...
u_str ESTAB 0 0 * 157937 * 157387 users:(("kubelet",pid=5714,fd=33))
u_str ESTAB 0 0 /var/run/docker.sock 157387 * 157937 users:(("dockerd",pid=1186,fd=14))
...Wie Sie sich erinnern, ist dies der Prozess des Docker-Daemons (pid=1186), der unseren Befehl ausführt:
// worker node
$ ps -afx
...
1186 ? Ssl 0:55 /usr/bin/dockerd -H fd://
17784 ? Sl 0:00 _ docker-containerd-shim 53a0a08547b2f95986402d7f3b3e78702516244df049ba6c5aa012e81264aa3c /var/run/docker/libcontainerd/53a0a08547b2f95986402d7f3
17801 pts/2 Ss 0:00 _ sh
17827 pts/2 S+ 0:00 _ sleep 5000
...4. Aktivität in der Ausführungsumgebung des Containers
Lassen Sie uns den Quellcode von CRI-O untersuchen, um zu verstehen, was passiert. In Docker ist die Logik ähnlich.
Es gibt einen Server, der für die Implementierung zuständig ist RuntimeServiceServer:
// Server implements the RuntimeService and ImageService
type Server struct {
config libconfig.Config
seccompProfile *seccomp.Seccomp
stream StreamService
netPlugin ocicni.CNIPlugin
hostportManager hostport.HostPortManager
appArmorProfile string
hostIP string
bindAddress string
*lib.ContainerServer
monitorsChan chan struct{}
defaultIDMappings *idtools.IDMappings
systemContext *types.SystemContext // Never nil
updateLock sync.RWMutex
seccompEnabled bool
appArmorEnabled bool
}()
// Exec prepares a streaming endpoint to execute a command in the container.
func (s *Server) Exec(ctx context.Context, req *pb.ExecRequest) (resp *pb.ExecResponse, err error) {
const operation = "exec"
defer func() {
recordOperation(operation, time.Now())
recordError(operation, err)
}()
resp, err = s.getExec(req)
if err != nil {
return nil, fmt.Errorf("unable to prepare exec endpoint: %v", err)
}
return resp, nil
}()
Am Ende der Kette führt die Ausführungsumgebung des Containers den Befehl auf dem Arbeitsknoten aus:
// ExecContainer prepares a streaming endpoint to execute a command in the container.
func (r *runtimeOCI) ExecContainer(c *Container, cmd []string, stdin io.Reader, stdout, stderr io.WriteCloser, tty bool, resize <-chan remotecommand.TerminalSize) error {
processFile, err := prepareProcessExec(c, cmd, tty)
if err != nil {
return err
}
defer os.RemoveAll(processFile.Name())
args := []string{rootFlag, r.root, "exec"}
args = append(args, "--process", processFile.Name(), c.ID())
execCmd := exec.Command(r.path, args...)
if v, found := os.LookupEnv("XDG_RUNTIME_DIR"); found {
execCmd.Env = append(execCmd.Env, fmt.Sprintf("XDG_RUNTIME_DIR=%s", v))
}
var cmdErr, copyError error
if tty {
cmdErr = ttyCmd(execCmd, stdin, stdout, resize)
} else {
if stdin != nil {
// Use an os.Pipe here as it returns true *os.File objects.
// This way, if you run 'kubectl exec <pod> -i bash' (no tty) and type 'exit',
// the call below to execCmd.Run() can unblock because its Stdin is the read half
// of the pipe.
r, w, err := os.Pipe()
if err != nil {
return err
}
go func() { _, copyError = pools.Copy(w, stdin) }()
execCmd.Stdin = r
}
if stdout != nil {
execCmd.Stdout = stdout
}
if stderr != nil {
execCmd.Stderr = stderr
}
cmdErr = execCmd.Run()
}
if copyError != nil {
return copyError
}
if exitErr, ok := cmdErr.(*exec.ExitError); ok {
return &utilexec.ExitErrorWrapper{ExitError: exitErr}
}
return cmdErr
}()
Schließlich führt der Kernel die Befehle aus:
Erinnerungen
- Der API-Server kann ebenfalls die Verbindung zum Kubelet initialisieren.
- Die folgenden Verbindungen bleiben bis zum Ende der interaktiven exec-Sitzung bestehen:
- zwischen kubectl und dem API-Server;
- zwischen dem API-Server und kubectl;
- zwischen dem Kubelet und der Ausführungsumgebung des Containers.
- Kubectl oder der API-Server können nichts auf den Arbeitsknoten starten. Das Kubelet kann starten, interagiert aber auch mit der Ausführungsumgebung des Containers für diese Aktionen.
Ressourcen
- Diskussion „“ in kubernetes-dev;
- Artikel „»;
- Diskussion „“ auf Server Fault.
P.S. vom Übersetzer
Lesen Sie auch in unserem Blog:
- „Was passiert in Kubernetes, wenn ich kubectl run starte?“ und ;
- «»;
- «»;
- «».
Quelle: habr.com
