نوٹ. ترجمہ: مضمون کے مصنف - ایرکن ایرول، ایس اے پی کے ایک انجینئر - ٹیم کے کام کرنے کے طریقہ کار کے بارے میں اپنا مطالعہ شیئر کرتے ہیں kubectl exec, Kubernetes کے ساتھ کام کرنے والے ہر ایک سے بہت واقف ہیں۔ وہ Kubernetes سورس کوڈ (اور متعلقہ پروجیکٹس) کی فہرستوں کے ساتھ پورے الگورتھم کے ساتھ ہے، جو آپ کو ضرورت کے مطابق موضوع کو گہرائی سے سمجھنے کی اجازت دیتا ہے۔
ایک جمعہ کو، ایک ساتھی میرے پاس آیا اور پوچھا کہ پوڈ کا استعمال کرتے ہوئے کمانڈ کو کیسے چلایا جائے۔ . میں اسے جواب نہیں دے سکا اور اچانک مجھے احساس ہوا کہ مجھے آپریشن کے طریقہ کار کے بارے میں کچھ نہیں معلوم kubectl exec. ہاں، مجھے اس کی ساخت کے بارے میں کچھ خیالات تھے، لیکن مجھے ان کی درستگی کا 100% یقین نہیں تھا اور اس لیے اس مسئلے سے نمٹنے کا فیصلہ کیا۔ بلاگز، دستاویزات اور سورس کوڈ کا مطالعہ کرنے کے بعد، میں نے بہت سی نئی چیزیں سیکھی ہیں، اور اس مضمون میں میں اپنی دریافتوں اور تفہیم کو شیئر کرنا چاہتا ہوں۔ اگر کچھ غلط ہے تو، براہ کرم مجھ سے رابطہ کریں۔ .
ٹریننگ
MacBook پر کلسٹر بنانے کے لیے، میں نے کلون کیا۔ . پھر میں نے کیوبلیٹ کنفیگریشن میں نوڈس کے آئی پی ایڈریسز کو درست کیا، کیونکہ ڈیفالٹ سیٹنگز اجازت نہیں دیتی تھیں۔ kubectl exec. آپ اس کی بنیادی وجہ کے بارے میں مزید پڑھ سکتے ہیں۔ .
- کوئی بھی کار = میری میک بک
- ماسٹر نوڈ IP = 192.168.205.10
- ورکر نوڈ IP = 192.168.205.11
- API سرور پورٹ = 6443
اجزاء
- kubectl exec عمل: جب ہم "kubectl exec..." پر عمل کرتے ہیں تو عمل شروع ہو جاتا ہے۔ یہ K8s API سرور تک رسائی کے ساتھ کسی بھی مشین پر کیا جا سکتا ہے۔ نوٹ ترجمہ: مزید کنسول کی فہرستوں میں، مصنف "کوئی بھی مشین" کا تبصرہ استعمال کرتا ہے، جس کا مطلب یہ ہے کہ اس کے بعد کے احکامات کوبرنیٹس تک رسائی کے ساتھ ایسی کسی بھی مشین پر عمل میں لایا جا سکتا ہے۔
- : ماسٹر نوڈ پر ایک جزو جو Kubernetes API تک رسائی فراہم کرتا ہے۔ یہ کبرنیٹس میں کنٹرول طیارے کا فرنٹ اینڈ ہے۔
- : ایک ایجنٹ جو کلسٹر میں ہر نوڈ پر چلتا ہے۔ یہ پھلی میں کنٹینرز کے آپریشن کو یقینی بناتا ہے۔
- (کنٹینر رن ٹائم): کنٹینرز چلانے کے لیے ذمہ دار سافٹ ویئر۔ مثالیں: Docker، CRI-O، کنٹینرڈ…
- اشٹھی: ورکر نوڈ پر 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 5000kubectl عمل ظاہر ہوتا ہے (ہمارے معاملے میں 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 exec subresource کے ساتھ POST کی درخواست تخلیق کرتا ہے اور 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)()
2. ماسٹر نوڈ سائیڈ پر سرگرمی
ہم اے پی آئی سرور سائیڈ پر بھی درخواست کا مشاہدہ کر سکتے ہیں:
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 درخواست میں پروٹوکول کو تبدیل کرنے کی درخواست شامل ہے۔ آپ کو انفرادی 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
}()
مطلوبہ اعمال انجام دینے کے لیے، api-server کو معلوم ہونا چاہیے کہ اسے کس پوڈ سے رابطہ کرنے کی ضرورت ہے:
// 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")
}()
یقینا، اختتامی نقطہ کے بارے میں ڈیٹا نوڈ کے بارے میں معلومات سے لیا گیا ہے:
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)()
ہورے! کیوبلیٹ کے پاس اب ایک بندرگاہ ہے (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
}()
دستاویزات سے :
یہ کنکشن کبلیٹ کے HTTPS اینڈ پوائنٹ سے بنائے گئے ہیں۔ پہلے سے طے شدہ طور پر، apiserver کیوبلیٹ کے سرٹیفکیٹ کی تصدیق نہیں کرتا، جو کنکشن کو مین-ان-دی-مڈل (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
}()
آئیے دیکھتے ہیں کہ ماسٹر نوڈ پر کیا ہو رہا ہے۔
سب سے پہلے، ہم ورکر نوڈ کا 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پھر کبلیٹ پورٹ سیٹ کریں (ہمارے معاملے میں 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
…لیکن انتظار کریں: کبلیٹ نے اسے کیسے نکالا؟ کیوبلیٹ میں ایک ڈیمون ہے جو API سرور کی درخواستوں کے لیے پورٹ کے ذریعے API تک رسائی فراہم کرتا ہے۔
// 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
}()
کوبیلیٹ 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
}()
الجھن میں نہ پڑو۔ یہ کمانڈ کا نتیجہ نہیں لوٹاتا ہے، لیکن مواصلت کا اختتامی نقطہ:
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:"-"`
}()
کوبیلیٹ انٹرفیس کو نافذ کرتا ہے۔ RuntimeServiceClient، جو کنٹینر رن ٹائم انٹرفیس کا حصہ ہے۔ (ہم نے اس کے بارے میں مزید لکھا، مثال کے طور پر، - تقریبا. ترجمہ):
kubernetes/kubernetes میں cri-api سے طویل فہرست
// 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)
}
()
یہ کنٹینر رن ٹائم انٹرفیس کے ذریعے کسی طریقہ کو کال کرنے کے لیے آسانی سے gRPC کا استعمال کرتا ہے:
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
}()
کنٹینر رن ٹائم عمل درآمد کے لیے ذمہ دار ہے۔ RuntimeServiceServer:
kubernetes/kubernetes میں cri-api سے طویل فہرست
// 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)
}
()
اگر ایسا ہے تو، ہمیں کبلیٹ اور کنٹینر کے رن ٹائم کے درمیان تعلق دیکھنا چاہیے، ٹھیک ہے؟ آؤ دیکھیں.
exec کمانڈ سے پہلے اور بعد میں اس کمانڈ کو چلائیں اور فرق کو دیکھیں۔ میرے معاملے میں فرق یہ ہے:
// worker node
$ ss -a -p |grep kubelet
...
u_str ESTAB 0 0 * 157937 * 157387 users:(("kubelet",pid=5714,fd=33))
...ہممم... کیوبلیٹ (pid=5714) اور کسی نامعلوم چیز کے درمیان یونکس ساکٹ کے ذریعے ایک نیا کنکشن۔ یہ کیا ہو سکتا ہے؟ یہ ٹھیک ہے، یہ ڈوکر ہے (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))
...جیسا کہ آپ کو یاد ہے، یہ ڈوکر ڈیمون عمل (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 سورس کوڈ کا جائزہ لیتے ہیں کہ کیا ہو رہا ہے۔ ڈوکر میں منطق ایک جیسی ہے۔
نفاذ کے لیے ایک سرور ذمہ دار ہے۔ 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
}()
سلسلہ کے اختتام پر، کنٹینر کا رن ٹائم ورکر نوڈ پر کمانڈ پر عمل کرتا ہے:
// 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
}()
آخر میں، دانا حکم دیتا ہے:
یاد دہانیاں
- API سرور کوبیلیٹ سے کنکشن بھی شروع کر سکتا ہے۔
- انٹرایکٹو ایگزیک سیشن ختم ہونے تک درج ذیل کنکشن برقرار رہتے ہیں:
- kubectl اور api-server کے درمیان؛
- api-server اور kubectl کے درمیان؛
- کیوبلیٹ اور کنٹینر کے رن ٹائم کے درمیان۔
- Kubectl یا api-server ورکر نوڈس پر کچھ نہیں چلا سکتا۔ Kubelet چل سکتا ہے، لیکن یہ ان چیزوں کو کرنے کے لیے کنٹینر کے رن ٹائم کے ساتھ بھی تعامل کرتا ہے۔
وسائل
- بحث ""kubernetes-dev میں؛
- آرٹیکل "؛ "
- بحث ""سرور کی خرابی پر۔
مترجم سے PS
ہمارے بلاگ پر بھی پڑھیں:
- "جب آپ kubectl رن چلاتے ہیں تو Kubernetes میں کیا ہوتا ہے؟" и ;
- «؛ "
- «؛ "
- «'.
ماخذ: www.habr.com