🥇 តើ kubectl exec ដំណើរការយ៉ាងដូចម្តេច?

ចំណាំ។ បកប្រែ៖ អ្នកនិពន្ធអត្ថបទ - Erkan Erol វិស្វករមកពី SAP - ចែករំលែកការសិក្សារបស់គាត់អំពីយន្តការនៃដំណើរការក្រុម kubectl execដូច្នេះស្គាល់គ្រប់គ្នាដែលធ្វើការជាមួយ Kubernetes ។ គាត់អមជាមួយក្បួនដោះស្រាយទាំងមូលជាមួយនឹងការចុះបញ្ជីនៃកូដប្រភព Kubernetes (និងគម្រោងពាក់ព័ន្ធ) ដែលអនុញ្ញាតឱ្យអ្នកយល់ពីប្រធានបទយ៉ាងស៊ីជម្រៅតាមតម្រូវការ។

ថ្ងៃសុក្រមួយ សហសេវិកម្នាក់បានមករកខ្ញុំ ហើយសួរពីរបៀបប្រតិបត្តិពាក្យបញ្ជានៅក្នុងផតដោយប្រើ អតិថិជនទៅ. ខ្ញុំមិនអាចឆ្លើយគាត់បានទេ ហើយស្រាប់តែដឹងថាខ្ញុំមិនដឹងអ្វីសោះអំពីយន្តការនៃការប្រតិបត្តិការ kubectl exec. បាទ/ចាស ខ្ញុំមានគំនិតជាក់លាក់អំពីរចនាសម្ព័ន្ធរបស់វា ប៉ុន្តែខ្ញុំមិនប្រាកដ 100% នៃភាពត្រឹមត្រូវរបស់ពួកគេទេ ដូច្នេះហើយបានសម្រេចចិត្តដោះស្រាយបញ្ហានេះ។ ដោយបានសិក្សាប្លុក ឯកសារ និងកូដប្រភព ខ្ញុំបានរៀនអ្វីថ្មីៗជាច្រើន ហើយនៅក្នុងអត្ថបទនេះ ខ្ញុំចង់ចែករំលែកការរកឃើញ និងការយល់ដឹងរបស់ខ្ញុំ។ បើមានអ្វីខុស សូមទាក់ទងមកខ្ញុំតាមលេខ Twitter.

ការរៀបចំ

ដើម្បីបង្កើតចង្កោមនៅលើ MacBook ខ្ញុំបានក្លូន ecomm-integration-ballerina/kubernetes-cluster. បន្ទាប់មកខ្ញុំបានកែអាសយដ្ឋាន IP របស់ថ្នាំងនៅក្នុងការកំណត់ kubelet ចាប់តាំងពីការកំណត់លំនាំដើមមិនអនុញ្ញាត។ kubectl exec. អ្នកអាចអានបន្ថែមអំពីហេតុផលចម្បងសម្រាប់រឿងនេះ នៅទីនេះ.

រថយន្តណាមួយ = ម៉ាស៊ីន MacBook របស់ខ្ញុំ
ថ្នាំងមេ IP = 192.168.205.10
ថ្នាំង IP = 192.168.205.11
ច្រកម៉ាស៊ីនមេ API = 6443

សមាសភាគ

kubectl ដំណើរការ exec៖ នៅពេលដែលយើងប្រតិបត្តិ “kubectl exec…” ដំណើរការត្រូវបានចាប់ផ្តើម។ នេះអាចត្រូវបានធ្វើនៅលើម៉ាស៊ីនណាមួយដែលមានសិទ្ធិចូលប្រើម៉ាស៊ីនមេ K8s API ។ ចំណាំ បកប្រែ៖ បន្ថែមទៀតនៅក្នុងបញ្ជីកុងសូល អ្នកនិពន្ធប្រើមតិយោបល់ "ម៉ាស៊ីនណាមួយ" ដោយបង្កប់ន័យថាពាក្យបញ្ជាជាបន្តបន្ទាប់អាចត្រូវបានប្រតិបត្តិលើម៉ាស៊ីនបែបនេះដែលមានសិទ្ធិចូលប្រើ Kubernetes ។
ម៉ាស៊ីនមេ api៖ សមាសធាតុមួយនៅលើថ្នាំងមេដែលផ្តល់សិទ្ធិចូលប្រើ Kubernetes API ។ នេះគឺជាផ្នែកខាងមុខសម្រាប់យន្តហោះបញ្ជានៅក្នុង Kubernetes ។
គូប៖ ភ្នាក់ងារដែលដំណើរការលើគ្រប់ node ក្នុង cluster ។ វាធានានូវប្រតិបត្តិការនៃធុងនៅក្នុងផត។
រយៈពេលដំណើរការកុងតឺន័រ (container runtime): កម្មវិធីដែលទទួលខុសត្រូវសម្រាប់ដំណើរការកុងតឺន័រ។ ឧទាហរណ៍៖ Docker, CRI-O, container...
ខឺណែល៖ ខឺណែល OS នៅលើថ្នាំងកម្មករ; ទទួលខុសត្រូវចំពោះការគ្រប់គ្រងដំណើរការ។
គោលដៅ (គោលដៅ) ធុង៖ ធុងដែលជាផ្នែកមួយនៃផត ហើយដំណើរការលើថ្នាំងកម្មករមួយ។

អ្វីដែលខ្ញុំបានរកឃើញ

1. សកម្មភាពរបស់អតិថិជន

បង្កើតផតនៅក្នុងលំហឈ្មោះ 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 រួមបញ្ចូលសំណើដើម្បីផ្លាស់ប្តូរពិធីការ។ អេសភីឌី អនុញ្ញាតឱ្យអ្នក multiplex បុគ្គល stdin/stdout/stderr/spdy-error "streams" លើការតភ្ជាប់ 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)

ជាការពិតណាស់ ទិន្នន័យអំពីចំណុចបញ្ចប់គឺយកចេញពីព័ត៌មានអំពីថ្នាំង៖

        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 > Master to Cluster > apiserver to kubelet:

ការតភ្ជាប់ទាំងនេះត្រូវបានធ្វើឡើងទៅកាន់ចំណុចបញ្ចប់ HTTPS របស់ kubelet ។ តាមលំនាំដើម apiserver មិនផ្ទៀងផ្ទាត់វិញ្ញាបនបត្ររបស់ kubelet ដែលធ្វើឱ្យការតភ្ជាប់ងាយរងការវាយប្រហារដោយ man-in-the-middle (MITM) និង មិនមានសុវត្ថិភាព សម្រាប់ធ្វើការនៅក្នុងបណ្តាញសាធារណៈដែលមិនគួរឱ្យទុកចិត្ត និង/ឬ។

ឥឡូវនេះម៉ាស៊ីនមេ API ដឹងពីចំណុចបញ្ចប់ និងបង្កើតការតភ្ជាប់៖

// 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    <none>   9h    v1.15.3   192.168.205.11   <none>        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. សកម្មភាពនៅលើថ្នាំងកម្មករ

ឥឡូវតោះភ្ជាប់ទៅថ្នាំងកម្មករ ហើយមើលអ្វីដែលកំពុងកើតឡើងនៅលើវា។

ដំបូងយើងឃើញថាការតភ្ជាប់ទៅវាត្រូវបានបង្កើតឡើងផងដែរ (បន្ទាត់ទីពីរ); 192.168.205.10 គឺជា IP របស់ថ្នាំងមេ៖

 // 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 គណនាចំណុចបញ្ចប់ការឆ្លើយតបសម្រាប់សំណើប្រតិបត្តិ៖

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)

កុំច្រឡំ។ វាមិនត្រឡប់លទ្ធផលនៃពាក្យបញ្ជានោះទេ ប៉ុន្តែចំណុចបញ្ចប់សម្រាប់ការទំនាក់ទំនង៖

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:"-"`
}

(cri-api/pkg/apis/runtime/v1alpha2/api.pb.go)

Kubelet អនុវត្តចំណុចប្រទាក់ RuntimeServiceClientដែលជាផ្នែកមួយនៃ Container Runtime Interface (យើងបានសរសេរបន្ថែមអំពីវា ជាឧទាហរណ៍ នៅទីនេះ - ប្រហែល បកប្រែ។ ):

បញ្ជីវែងពី cri-api នៅក្នុង 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)
}

(cri-api/pkg/apis/runtime/v1alpha2/api.pb.go)
វាគ្រាន់តែប្រើ gRPC ដើម្បីហៅវិធីសាស្ត្រតាមរយៈ Container Runtime Interface៖

type runtimeServiceClient struct {
        cc *grpc.ClientConn
}

(cri-api/pkg/apis/runtime/v1alpha2/api.pb.go)

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
}

(cri-api/pkg/apis/runtime/v1alpha2/api.pb.go)

Container Runtime ទទួលខុសត្រូវចំពោះការអនុវត្ត RuntimeServiceServer:

បញ្ជីវែងពី cri-api នៅក្នុង 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)
}

(cri-api/pkg/apis/runtime/v1alpha2/api.pb.go)

បើអញ្ចឹង យើងគួរតែឃើញការតភ្ជាប់រវាង kubelet និងកុងតឺន័រ runtime មែនទេ? សូមពិនិត្យមើល។

ដំណើរការពាក្យបញ្ជានេះមុន និងក្រោយពាក្យបញ្ជា exec ហើយមើលភាពខុសគ្នា។ ក្នុងករណីរបស់ខ្ញុំភាពខុសគ្នាគឺ៖

// worker node
$ ss -a -p |grep kubelet
...
u_str  ESTAB      0      0       * 157937                * 157387                users:(("kubelet",pid=5714,fd=33))
...

ហ៊ឺម... ការតភ្ជាប់ថ្មីតាមរយៈរន្ធ unix រវាង kubelet (pid=5714) និងអ្វីមួយដែលមិនស្គាល់។ តើវាអាចជាអ្វី? ត្រូវហើយ វាជា 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))
...

ដូចដែលអ្នកចងចាំ នេះគឺជាដំណើរការ docker daemon (pid=1186) ដែលប្រតិបត្តិពាក្យបញ្ជារបស់យើង៖

// 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. សកម្មភាពនៅក្នុងពេលដំណើរការកុងតឺន័រ

ចូរយើងពិនិត្យមើលកូដប្រភព CRI-O ដើម្បីយល់ពីអ្វីដែលកំពុងកើតឡើង។ នៅក្នុង Docker តក្កវិជ្ជាគឺស្រដៀងគ្នា។

មានម៉ាស៊ីនមេដែលទទួលខុសត្រូវក្នុងការអនុវត្ត 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
}

(cri-o/server/server.go)

// 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
}

(cri-o/erver/container_exec.go)

នៅចុងបញ្ចប់នៃខ្សែសង្វាក់ កុងតឺន័រដំណើរការ ដំណើរការពាក្យបញ្ជានៅលើថ្នាំងកម្មករ៖

// 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
}

(cri-o/internal/oci/runtime_oci.go)

ជាចុងក្រោយ ខឺណែលប្រតិបត្តិពាក្យបញ្ជា៖

апоминания

API Server ក៏អាចចាប់ផ្តើមការតភ្ជាប់ទៅ kubelet ផងដែរ។
ការតភ្ជាប់ខាងក្រោមនៅតែបន្តរហូតដល់វគ្គ exec អន្តរកម្មបញ្ចប់៖
- រវាង kubectl និង api-server;
- រវាង api-server និង kubectl;
- រវាង kubelet និងកុងតឺន័រដំណើរការ។
Kubectl ឬ api-server មិនអាចដំណើរការអ្វីនៅលើថ្នាំងកម្មករបានទេ។ Kubelet អាចដំណើរការបាន ប៉ុន្តែវាក៏មានអន្តរកម្មជាមួយនឹងកុងតឺន័រដំណើរការផងដែរ ដើម្បីធ្វើកិច្ចការទាំងនោះ។

ធនធាន

ការពិភាក្សា "តើ "kubectl exec" ដំណើរការយ៉ាងដូចម្តេច" នៅក្នុង kubernetes-dev;
អត្ថបទ "លេងជាមួយ kubeadm នៅក្នុង Vagrant Machines, Part 2»
ការពិភាក្សា "តើធ្វើដូចម្តេចដើម្បីស្វែងរកចុងបញ្ចប់ផ្សេងទៀតនៃការតភ្ជាប់រន្ធ unix?"នៅលើ Server កំហុស។

PS ពីអ្នកបកប្រែ

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

"តើមានអ្វីកើតឡើងនៅក្នុង Kubernetes នៅពេលអ្នកដំណើរការ kubectl run?" ផ្នែកនៃ 1 и ផ្នែកទី ២;
«ដូច្នេះតើអ្វីជា pod នៅក្នុង Kubernetes?»
«តើកម្មវិធីកំណត់ពេល Kubernetes ពិតជាដំណើរការយ៉ាងដូចម្តេច?»
«វិធីដើម្បីសម្រេចបាននូវភាពអាចរកបានខ្ពស់នៅក្នុង Kubernetes"។

ប្រភព: www.habr.com

តើ kubectl exec ដំណើរការយ៉ាងដូចម្តេច?

ការរៀបចំ

សមាសភាគ

អ្វីដែលខ្ញុំបានរកឃើញ

1. សកម្មភាពរបស់អតិថិជន

2. សកម្មភាពនៅផ្នែកខាងថ្នាំងមេ

3. សកម្មភាពនៅលើថ្នាំងកម្មករ

4. សកម្មភាពនៅក្នុងពេលដំណើរការកុងតឺន័រ

апоминания

ធនធាន

PS ពីអ្នកបកប្រែ

បន្ថែមមតិយោបល់ ответОтменить