1 深度剖析-CRI篇
目前我司现网的K8s集群的运行时已经完成从docker到Containerd的切换,有小伙伴对K8s与Containerd调用链涉及的组件不了解,其中Containerd和RunC是什么关系,docker和containerd又有什么区别,以及K8s调用Containerd创建容器又是怎样的流程,最终RunC又是如何创建容器的,诸如此类的疑问。本文就针对K8s使用Containerd作为运行时的整个调用链进行介绍和源码级别的分析。 其中关于kubelet与运行时的分层架构图可以参看下图:
那么关于各类运行时的介绍可以参看Containerd深度剖析-runtime篇
## 1.1 “运行时简介”
容器运行时意思就是能够管理容器运行的整个生命周期,具体一点就是如何制作容器的镜像、容器镜像格式是什么样子的、管理容器的镜像、容器镜像的分发、如何运行一个容器以及管理创建的容器实例等等。
容器运行时有一个行业标准叫做OCI规范,这个规范分成两部分:
a. 容器运行时规范:描述了如何通过一个bundle运行容器,bundle就是一个目录,里面包括一个容器的规格文件,文件叫 config.json 和一个rootfs,rootfs中包含了一个容器运行时所需操作系统的文件。
b. 容器镜像规范:定义了容器的镜像如何打包如何将镜像转换成一个bundle。
目前流行将运行时分成low-level运行时和high-level运行时,low-level运行时专注于如何创建一个容器例如runc和kata,high-level包含了更多上层功能,比如镜像管理,以docker和containerd为代表。 K8s的kubelet是调用容器运行时创建容器的,但是容器运行时这么多不可能逐个兼容,K8s在对接容器运行时定义了CRI接口,容器运行时只需实现该接口就能被使用。下图分别是k8s使用docker和containerd的调用链,使用containerd时CRI接口是在containerd代码中实现的;使用docker时的CRI接口是在k8s的代码中实现的,叫做docker-shim(kubernetes/pkg/kubelet/dockershim/docker_service.go),这部分代码在k8s代码中是历史原因,当时docker是容器方面行业事实上的标准,但随着越来越多运行时实现了CRI支持,docker-shim的维护日益变成社区负担,在最新的K8s版本中,该部分代码目前已经移出,暂时由mirantis进行维护,下图是插件的发展历程。![🐧[Containerd] 深度剖析-CRI篇 - 图2](/uploads/projects/seekerzw@yaaygq/45222dea608c48f946be9f94a2e9420a.png)
1.2 “Containerd CRI简介”
Containerd是一个行业标准的容器运行时,它是一个daemon进程,可以管理主机上容器的全部生命周期和它的文件系统,包括:镜像的分发和存储、容器的运行和监控,底层的存储和网络。![🐧[Containerd] 深度剖析-CRI篇 - 图3](/uploads/projects/seekerzw@yaaygq/8857fe9d9a705e1109805ed56d7f65d0.png)
go
// Runtime service defines the public APIs for remote container runtimes
service RuntimeService {
// Version returns the runtime name, runtime version, and runtime API version.
rpc Version(VersionRequest) returns (VersionResponse) {}
// RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure
// the sandbox is in the ready state on success.
rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}
// 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.
rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}
// 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.
rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}
// PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not
// present, returns an error.
rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}
// ListPodSandbox returns a list of PodSandboxes.
rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}
// CreateContainer creates a new container in specified PodSandbox
rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}
// StartContainer starts the container.
rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}
// 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.
// The runtime must forcibly kill the container after the grace period is
// reached.
rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}
// 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.
rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}
// ListContainers lists all containers by filters.
rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}
// ContainerStatus returns status of the container. If the container is not
// present, returns an error.
rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}
// UpdateContainerResources updates ContainerConfig of the container synchronously.
// If runtime fails to transactionally update the requested resources, an error is returned.
rpc UpdateContainerResources(UpdateContainerResourcesRequest) returns (UpdateContainerResourcesResponse) {}
// 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.
rpc ReopenContainerLog(ReopenContainerLogRequest) returns (ReopenContainerLogResponse) {}
// ExecSync runs a command in a container synchronously.
rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {}
// Exec prepares a streaming endpoint to execute a command in the container.
rpc Exec(ExecRequest) returns (ExecResponse) {}
// Attach prepares a streaming endpoint to attach to a running container.
rpc Attach(AttachRequest) returns (AttachResponse) {}
// PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
rpc PortForward(PortForwardRequest) returns (PortForwardResponse) {}
// ContainerStats returns stats of the container. If the container does not
// exist, the call returns an error.
rpc ContainerStats(ContainerStatsRequest) returns (ContainerStatsResponse) {}
// ListContainerStats returns stats of all running containers.
rpc ListContainerStats(ListContainerStatsRequest) returns (ListContainerStatsResponse) {}
// PodSandboxStats returns stats of the pod sandbox. If the pod sandbox does not
// exist, the call returns an error.
rpc PodSandboxStats(PodSandboxStatsRequest) returns (PodSandboxStatsResponse) {}
// ListPodSandboxStats returns stats of the pod sandboxes matching a filter.
rpc ListPodSandboxStats(ListPodSandboxStatsRequest) returns (ListPodSandboxStatsResponse) {}
// UpdateRuntimeConfig updates the runtime configuration based on the given request.
rpc UpdateRuntimeConfig(UpdateRuntimeConfigRequest) returns (UpdateRuntimeConfigResponse) {}
// Status returns the status of the runtime.
rpc Status(StatusRequest) returns (StatusResponse) {}
}
// ImageService defines the public APIs for managing images.
service ImageService {
// ListImages lists existing images.
rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {}
// ImageStatus returns the status of the image. If the image is not
// present, returns a response with ImageStatusResponse.Image set to
// nil.
rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse) {}
// PullImage pulls an image with authentication config.
rpc PullImage(PullImageRequest) returns (PullImageResponse) {}
// RemoveImage removes the image.
// This call is idempotent, and must not return an error if the image has
// already been removed.
rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse) {}
// ImageFSInfo returns information of the filesystem that is used to store images.
rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {}
}
kubelet调用CRI接口创建一个包含A和B两个业务container的Pod流程如下所示:
① 为Pod创建sandbox
② 创建container A
③ 启动container A
④ 创建container B
⑤ 启动container B
![🐧[Containerd] 深度剖析-CRI篇 - 图4](/uploads/projects/seekerzw@yaaygq/1dd5ac1b197fba95c08ecd6f56c100aa.png)
1.3 “Containerd CRI实现”
RunPodSandbox
RunPodSandbox的流程如下: ① 拉取sandbox的镜像,在containerd中配置 ② 获取创建pod要使用的runtime,可以在创建pod的yaml中指定,如果没指定使用containerd中默认的(runtime在containerd中配置) ③ 如果pod不是hostNetwork那么添加创建新net namespace,并使用cni插件设置网络(criService在初始化时会加载containerd中cri指定的插件信息) ④ 调用containerd客户端创建一个container ⑤ 在rootDir/io.containerd.grpc.v1.cri/sandboxes下为当前pod以pod Id为名创建一个目录(pkg/cri/cri.go) ⑥ 根据选择的runtime为sandbox容器创建task ⑦ 启动sandbox容器的task,将sandbox添加到数据库中 代码在containerd/pkg/cri/server/sanbox_run.go 中
// RunPodSandbox creates and starts a pod-level sandbox. Runtimes should ensure// the sandbox is in ready state.func (c *criService) RunPodSandbox(ctx context.Context, r *runtime.RunPodSandboxRequest) (_ *runtime.RunPodSandboxResponse, retErr error) {config := r.GetConfig()log.G(ctx).Debugf("Sandbox config %+v", config)// Generate unique id and name for the sandbox and reserve the name.id := util.GenerateID()metadata := config.GetMetadata()if metadata == nil {return nil, errors.New("sandbox config must include metadata")}name := makeSandboxName(metadata)log.G(ctx).WithField("podsandboxid", id).Debugf("generated id for sandbox name %q", name)// cleanupErr records the last error returned by the critical cleanup operations in deferred functions,// like CNI teardown and stopping the running sandbox task.// If cleanup is not completed for some reason, the CRI-plugin will leave the sandbox// in a not-ready state, which can later be cleaned up by the next execution of the kubelet's syncPod workflow.var cleanupErr error// Reserve the sandbox name to avoid concurrent `RunPodSandbox` request starting the// same sandbox.if err := c.sandboxNameIndex.Reserve(name, id); err != nil {return nil, fmt.Errorf("failed to reserve sandbox name %q: %w", name, err)}defer func() {// Release the name if the function returns with an error.// When cleanupErr != nil, the name will be cleaned in sandbox_remove.if retErr != nil && cleanupErr == nil {c.sandboxNameIndex.ReleaseByName(name)}}()var (err errorsandboxInfo = sb.Sandbox{ID: id})ociRuntime, err := c.getSandboxRuntime(config, r.GetRuntimeHandler())if err != nil {return nil, fmt.Errorf("unable to get OCI runtime for sandbox %q: %w", id, err)}sandboxInfo.Runtime.Name = ociRuntime.Type// Retrieve runtime optionsruntimeOpts, err := generateRuntimeOptions(ociRuntime, c.config)if err != nil {return nil, fmt.Errorf("failed to generate sandbox runtime options: %w", err)}...// Create initial internal sandbox object.sandbox := sandboxstore.NewSandbox(...)if _, err := c.client.SandboxStore().Create(ctx, sandboxInfo); err != nil {return nil, fmt.Errorf("failed to save sandbox metadata: %w", err)}...// Setup the network namespace if host networking wasn't requested.if !hostNetwork(config) {netStart := time.Now()// If it is not in host network namespace then create a namespace and set the sandbox// handle. NetNSPath in sandbox metadata and NetNS is non empty only for non host network// namespaces. If the pod is in host network namespace then both are empty and should not// be used.var netnsMountDir = "/var/run/netns"if c.config.NetNSMountsUnderStateDir {netnsMountDir = filepath.Join(c.config.StateDir, "netns")}sandbox.NetNS, err = netns.NewNetNS(netnsMountDir)if err != nil {return nil, fmt.Errorf("failed to create network namespace for sandbox %q: %w", id, err)}// Update network namespace in the store, which is used to generate the container's specsandbox.NetNSPath = sandbox.NetNS.GetPath()defer func() {// Remove the network namespace only if all the resource cleanup is doneif retErr != nil && cleanupErr == nil {if cleanupErr = sandbox.NetNS.Remove(); cleanupErr != nil {log.G(ctx).WithError(cleanupErr).Errorf("Failed to remove network namespace %s for sandbox %q", sandbox.NetNSPath, id)return}sandbox.NetNSPath = ""}}()if err := sandboxInfo.AddExtension(podsandbox.MetadataKey, &sandbox.Metadata); err != nil {return nil, fmt.Errorf("unable to save sandbox %q to store: %w", id, err)}// Save sandbox metadata to storeif sandboxInfo, err = c.client.SandboxStore().Update(ctx, sandboxInfo, "extensions"); err != nil {return nil, fmt.Errorf("unable to update extensions for sandbox %q: %w", id, err)}// Define this defer to teardownPodNetwork prior to the setupPodNetwork function call.// This is because in setupPodNetwork the resource is allocated even if it returns error, unlike other resource// creation functions.defer func() {// Remove the network namespace only if all the resource cleanup is done.if retErr != nil && cleanupErr == nil {deferCtx, deferCancel := ctrdutil.DeferContext()defer deferCancel()// Teardown network if an error is returned.if cleanupErr = c.teardownPodNetwork(deferCtx, sandbox); cleanupErr != nil {log.G(ctx).WithError(cleanupErr).Errorf("Failed to destroy network for sandbox %q", id)}}}()// Setup network for sandbox.// Certain VM based solutions like clear containers (Issue containerd/cri-containerd#524)// rely on the assumption that CRI shim will not be querying the network namespace to check the// network states such as IP.// In future runtime implementation should avoid relying on CRI shim implementation details.// In this case however caching the IP will add a subtle performance enhancement by avoiding// calls to network namespace of the pod to query the IP of the veth interface on every// SandboxStatus request.if err := c.setupPodNetwork(ctx, &sandbox); err != nil {return nil, fmt.Errorf("failed to setup network for sandbox %q: %w", id, err)}sandboxCreateNetworkTimer.UpdateSince(netStart)}if err := sandboxInfo.AddExtension(podsandbox.MetadataKey, &sandbox.Metadata); err != nil {return nil, fmt.Errorf("unable to save sandbox %q to store: %w", id, err)}controller, err := c.getSandboxController(config, r.GetRuntimeHandler())if err != nil {return nil, fmt.Errorf("failed to get sandbox controller: %w", err)}// Save sandbox metadata to storeif sandboxInfo, err = c.client.SandboxStore().Update(ctx, sandboxInfo, "extensions"); err != nil {return nil, fmt.Errorf("unable to update extensions for sandbox %q: %w", id, err)}runtimeStart := time.Now()if err := controller.Create(ctx, id); err != nil {return nil, fmt.Errorf("failed to create sandbox %q: %w", id, err)}resp, err := controller.Start(ctx, id)if err != nil {sandbox.Container, _ = c.client.LoadContainer(ctx, id)if resp != nil && resp.SandboxID == "" && resp.Pid == 0 && resp.CreatedAt == nil && len(resp.Labels) == 0 {// if resp is a non-nil zero-value, an error occurred during cleanupcleanupErr = fmt.Errorf("failed to cleanup sandbox")}return nil, fmt.Errorf("failed to start sandbox %q: %w", id, err)}// TODO: get rid of this. sandbox object should no longer have Container field.if ociRuntime.SandboxMode == string(criconfig.ModePodSandbox) {container, err := c.client.LoadContainer(ctx, id)if err != nil {return nil, fmt.Errorf("failed to load container %q for sandbox: %w", id, err)}sandbox.Container = container}labels := resp.GetLabels()if labels == nil {labels = map[string]string{}}sandbox.ProcessLabel = labels["selinux_label"]if err := sandbox.Status.Update(func(status sandboxstore.Status) (sandboxstore.Status, error) {// Set the pod sandbox as ready after successfully start sandbox container.status.Pid = resp.Pidstatus.State = sandboxstore.StateReadystatus.CreatedAt = protobuf.FromTimestamp(resp.CreatedAt)return status, nil}); err != nil {return nil, fmt.Errorf("failed to update sandbox status: %w", err)}// Add sandbox into sandbox store in INIT state.if err := c.sandboxStore.Add(sandbox); err != nil {return nil, fmt.Errorf("failed to add sandbox %+v into store: %w", sandbox, err)}// Send CONTAINER_CREATED event with both ContainerId and SandboxId equal to SandboxId.// Note that this has to be done after sandboxStore.Add() because we need to get// SandboxStatus from the store and include it in the event.c.generateAndSendContainerEvent(ctx, id, id, runtime.ContainerEventType_CONTAINER_CREATED_EVENT)// start the monitor after adding sandbox into the store, this ensures// that sandbox is in the store, when event monitor receives the TaskExit event.//// TaskOOM from containerd may come before sandbox is added to store,// but we don't care about sandbox TaskOOM right now, so it is fine.go func() {resp, err := controller.Wait(ctrdutil.NamespacedContext(), id)if err != nil {log.G(ctx).WithError(err).Error("failed to wait for sandbox controller, skipping exit event")return}e := &eventtypes.TaskExit{ContainerID: id,ID: id,// Pid is not usedPid: 0,ExitStatus: resp.ExitStatus,ExitedAt: resp.ExitedAt,}c.eventMonitor.backOff.enBackOff(id, e)}()// Send CONTAINER_STARTED event with ContainerId equal to SandboxId.c.generateAndSendContainerEvent(ctx, id, id, runtime.ContainerEventType_CONTAINER_STARTED_EVENT)sandboxRuntimeCreateTimer.WithValues(labels["oci_runtime_type"]).UpdateSince(runtimeStart)return &runtime.RunPodSandboxResponse{PodSandboxId: id}, nil}
CreateContainer
CreateContainer在指定的PodSandbox中创建一个新的container元数据,流程如下: ① 获取容器的sandbox信息 ② 为容器要用的镜像初始化镜像handler ③ 为容器在rootDir/io.containerd.grpc.v1.cri目录下以容器Id命名的目录 ④ 从sandbox中获取所使用的runtime ⑤ 为容器创建containerSpec ⑥ 使用containerd客户端创建container ⑦ 保存container的信息 代码见 containerd/pkg/cri/server/container_create.go 下面是省略过的代码。
func (c *criService) CreateContainer(ctx context.Context, r*runtime.CreateContainerRequest) (_ *runtime.CreateContainerResponse, retErr error) {sandbox, err := c.sandboxStore.Get(r.GetPodSandboxId())s, err := sandbox.Container.Task(ctx, nil)sandboxPid := s.Pid()image, err := c.localResolve(config.GetImage().GetImage())if err != nil {return nil, errors.Wrapf(err, "failed to resolve image %q", config.GetImage().GetImage())}containerdImage, err := c.toContainerdImage(ctx, image)// Run container using the same runtime with sandbox.sandboxInfo, err := sandbox.Container.Info(ctx)if err != nil {return nil, errors.Wrapf(err, "failed to get sandbox %q info", sandboxID)}// Create container root directory. containerRootDir := c.getContainerRootDir(id)if err = c.os.MkdirAll(containerRootDir, 0755); err != nil {return nil, errors.Wrapf(err, "failed to create container root directory %q", containerRootDir)}ociRuntime, err := c.getSandboxRuntime(sandboxConfig, sandbox.Metadata.RuntimeHandler)if err != nil {return nil, errors.Wrap(err, "failed to get sandbox runtime")}spec, err := c.containerSpec(id, sandboxID, sandboxPid, sandbox.NetNSPath, containerName, containerdImage.Name(), config, sandboxConfig,&image.ImageSpec.Config, append(mounts, volumeMounts...), ociRuntime)if err != nil {return nil, errors.Wrapf(err, "failed to generate container %q spec", id)}opts = append(opts, containerd.WithSpec(spec, specOpts...),containerd.WithRuntime(sandboxInfo.Runtime.Name, runtimeOptions), containerd.WithContainerLabels(containerLabels), containerd.WithContainerExtension(containerMetadataExtension, &meta))var cntr containerd.Containerif cntr, err = c.client.NewContainer(ctx, id, opts...); err != nil {return nil, errors.Wrap(err, "failed to create containerd container")}// Add container into container store.if err := c.containerStore.Add(container); err != nil {return nil, errors.Wrapf(err, "failed to add container %q into store", id)}}
StartContainer
StartContainer用于启动一个容器,流程如下: ① 读取保存的container元数据 ② 读取关联的sandbox信息 ③ 为容器创建task ④ 启动task 代码见 containerd/pkg/cri/server/container_start.go,下面是该部分省略过后的代码:创建task的代码如下,调用了containerd的客户端的TasksClient,向服务器端发送创建task的请求
func (c *criService) StartContainer(ctx context.Context, r *runtime.StartContainerRequest) (retRes *runtime.StartContainerResponse, retErr error) {cntr, err := c.containerStore.Get(r.GetContainerId())// Get sandbox config from sandbox store. sandbox, err := c.sandboxStore.Get(meta.SandboxID) ctrInfo, err := container.Info(ctx)if err != nil {return nil, errors.Wrap(err, "failed to get container info")}taskOpts := c.taskOpts(ctrInfo.Runtime.Name)task, err := container.NewTask(ctx, ioCreation, taskOpts...)if err != nil {return nil, errors.Wrap(err, "failed to create containerd task")}// wait is a long running background request, no timeout needed. exitCh, err := task.Wait(ctrdutil.NamespacedContext())// Start containerd task.if err := task.Start(ctx); err != nil {return nil, errors.Wrapf(err, "failed to start containerd task %q", id)}}
task启动的代码如下,调用了containerd的客户端的TasksClient,向服务器端发送启动task的请求。
func (c *container) NewTask(ctx context.Context, ioCreate cio.Creator, opts...NewTaskOpts) (_ Task, err error) {......request := &tasks.CreateTaskRequest{ContainerID: c.id,Terminal: cfg.Terminal, Stdin: cfg.Stdin,Stdout: cfg.Stdout,Stderr: cfg.Stderr,}......response, err := c.client.TaskService().Create(ctx, request)......
func (t *task) Start(ctx context.Context) error {r, err := t.client.TaskService().Start(ctx, &tasks.StartRequest{ContainerID: t.id,})if err != nil {if t.io != nil {t.io.Cancel()t.io.Close()}return errdefs.FromGRPC(err)}t.pid = r.Pidreturn nil}
1.4 “Task Service”
Task Service创建task流程
下面是tasks-service处理创建task请求的代码,根据容器运行时创建容器。runtime创建容器代码如下,启动了shim并向shim发送创建请求。
func (l *local) Create(ctx context.Context, r *api.CreateTaskRequest, _...grpc.CallOption) (*api.CreateTaskResponse, error) { container, err := l.getContainer(ctx, r.ContainerID)......rtime, err := l.getRuntime(container.Runtime.Name)if err != nil {return nil, err}_, err = rtime.Get(ctx, r.ContainerID)if err != nil && err != runtime.ErrTaskNotExists {return nil, errdefs.ToGRPC(err)}if err == nil {return nil, errdefs.ToGRPC(fmt.Errorf("task %s already exists", r.ContainerID))}c, err := rtime.Create(ctx, r.ContainerID, opts)......return &api.CreateTaskResponse{ContainerID: r.ContainerID, Pid: c.PID(),}, nil
startShim调用shim可执行文件启动了一个service,代码如下:
func (m *TaskManager) Create(ctx context.Context, id string, opts runtime.CreateOpts) (_ runtime.Task, retErr error) {......shim, err := m.startShim(ctx, bundle, id, opts)t, err := shim.Create(ctx, opts).....}
执行shim命令所使用的可执行文件是containerd-shim-
func (m *TaskManager) startShim(ctx context.Context, bundle *Bundle, id string, opts runtime.CreateOpts) (*shim, error) {......b := shimBinary(ctx, bundle, opts.Runtime, m.containerdAddress, m.containerdTTRPCAddress, m.events, m.tasks)shim, err := b.Start(ctx, topts, func() {log.G(ctx).WithField("id", id).Info("shim disconnected")cleanupAfterDeadShim(context.Background(), id, ns, m.tasks, m.events, b) m.tasks.Delete(ctx, id)})......
containerd-shim-runc-v2 -namespace xxxx -address xxxx -publish-binary xxxx -id xxxx start
func (b *binary) Start(ctx context.Context, opts *types.Any, onClose func()) (_ *shim, err error) {args := []string{"id", b.bundle.ID}args = append(args, "start")cmd, err :=client.Command(ctx,b.runtime,b.containerdAddress,b.containerdTTRPCAddress,b.bundle.Path,opts,args...,)......out, err := cmd.CombinedOutput()if err != nil {return nil, errors.Wrapf(err, "%s", out)}address := strings.TrimSpace(string(out))conn, err := client.Connect(address, client.AnonDialer)if err != nil {return nil, err}onCloseWithShimLog := func() {onClose()cancelShimLog()f.Close()}client := ttrpc.NewClient(conn, ttrpc.WithOnClose(onCloseWithShimLog))return &shim{bundle: b.bundle,client: client,}, nil
Task Service启动task流程
下面是tasks-service启动一个task的流程:启动容器的进程通过向shim的server端发送请求完成。
func (l *local) Start(ctx context.Context, r *api.StartRequest, _ ...grpc.CallOption) (*api.StartResponse, error) {t, err := l.getTask(ctx, r.ContainerID)if err != nil {return nil, err}p := runtime.Process(t)if r.ExecID != "" {if p, err = t.Process(ctx, r.ExecID); err != nil {return nil, errdefs.ToGRPC(err)}}if err := p.Start(ctx); err != nil {return nil, errdefs.ToGRPC(err)}state, err := p.State(ctx)if err != nil {return nil, errdefs.ToGRPC(err)}return &api.StartResponse{Pid: state.Pid,}, nil}
func (s *shim) Start(ctx context.Context) error {response, err := s.task.Start(ctx,&task.StartRequest{ID: s.ID(),})if err != nil {return errdefs.FromGRPC(err)}s.taskPid = int(response.Pid)return nil
1.5 “Containerd-shim启动流程”
containerd/runtime/v2/shim/shim.go 中是containerd-shim-runc-v2 start 的代码入口:
RunManager(ctx context.Context, manager Manager, opts ...BinaryOpts)
containerd-shim-runc-v2 start进程会再次创建一个containerd-shim-runc-v2 -namespace xxxx -id xxxx - address xxxx 的进程用于启动shim server。
case "start":opts := StartOpts{Address: addressFlag,TTRPCAddress: ttrpcAddress,Debug: debugFlag,}address, err := manager.Start(ctx, id, opts)if err != nil {return err}if _, err := os.Stdout.WriteString(address); err != nil {return err}return nil}
shim server是个ttrpc服务,提供如下接口:
func (manager) Start(ctx context.Context, id string, opts shim.StartOpts) (_ string, retErr error) {cmd, err := newCommand(ctx, id, opts.Address, opts.TTRPCAddress, opts.Debug)...// make sure that reexec shim-v2 binary use the value if needif err := shim.WriteAddress("address", address); err != nil {return "", err}...if err := cmd.Start(); err != nil {f.Close()return "", err}...// make sure to wait after startgo cmd.Wait()...server, err := newServer(ttrpc.WithUnaryServerInterceptor(unaryInterceptor))if err != nil {return fmt.Errorf("failed creating server: %w", err)}for _, srv := range ttrpcServices {if err := srv.RegisterTTRPC(server); err != nil {return fmt.Errorf("failed to register service: %w", err)}}if err := serve(ctx, server, signals, sd.Shutdown); err != nil {if err != shutdown.ErrShutdown {return err}}}
创建task是执行了runc create —bundle xxxx xxxx 命令,参考代码:
type TaskService interface {State(context.Context, *StateRequest) (*StateResponse, error)Create(context.Context, *CreateTaskRequest) (*CreateTaskResponse, error)Start(context.Context, *StartRequest) (*StartResponse, error)Delete(context.Context, *DeleteRequest) (*DeleteResponse, error)Pids(context.Context, *PidsRequest) (*PidsResponse, error)Pause(context.Context, *PauseRequest) (*emptypb.Empty, error)Resume(context.Context, *ResumeRequest) (*emptypb.Empty, error)Checkpoint(context.Context, *CheckpointTaskRequest) (*emptypb.Empty, error)Kill(context.Context, *KillRequest) (*emptypb.Empty, error)Exec(context.Context, *ExecProcessRequest) (*emptypb.Empty, error)ResizePty(context.Context, *ResizePtyRequest) (*emptypb.Empty, error)CloseIO(context.Context, *CloseIORequest) (*emptypb.Empty, error)Update(context.Context, *UpdateTaskRequest) (*emptypb.Empty, error)Wait(context.Context, *WaitRequest) (*WaitResponse, error)Stats(context.Context, *StatsRequest) (*StatsResponse, error)Connect(context.Context, *ConnectRequest) (*ConnectResponse, error)Shutdown(context.Context, *ShutdownRequest) (*emptypb.Empty, error)}
启动task是执行了runc start xxxx 命令,参考代码:
func (r *Runc) Create(context context.Context, id, bundle string, opts *CreateOpts) error{args := []string{"create", "bundle", bundle}......cmd := r.command(context, append(args, id)...)......ec, err := Monitor.Start(cmd)......}
小结 kubelet创建sandbox流程总结如下: ① containerd的cri模块创建sandbox元数据并保存 ② containerd的cri模块创建sandbox容器并保存 ③ containerd的cri模块通过grpc调用tasks-service创建task ④ tasks-service模块创建containerd-shim-xxxx-xxxx start 进程 ⑤ containerd-shim-xxxx-xxxx start 进程创建containerd-shim- xxxx-xxxx 进程并退出 ⑥ containerd-shim-xxxx-xxxx 进程启动shim server,提供ttrpc服务 ⑦ tasks-service模块调用shim server的Create接口,创建task,shim server 执行runc create 命令 ⑧ containerd的cri模块通过grpc调用tasks-service启动task ⑨ tasks-service模块调用shimserver的Start接口,启动task,shim server 执行runc start命令
func (r *Runc) Start(context context.Context, id string) error {return r.runOrError(r.command(context, "start", id))}
![🐧[Containerd] 深度剖析-CRI篇 - 图5](/uploads/projects/seekerzw@yaaygq/77850fcbd01da89f033807ce546ab2de.png)
2 Containerd深入浅出-安全容器篇
Containerd 是一个高度模块化的高级运行时,所有模块均可插拔,模块均以 RPC service 形式注册并调用(gRPC 或者 TTRPC)。不同插件通过声明互相依赖,由 Containerd 核心实现统一加载,使用方可以自行实现插件以实现定制化的功能。当然这种设计虽然使得 Containerd 拥有强大的跨平台、可插拔的能力,同时也带来一些缺点,模块之间功能互调必须通过 RPC 调用。2.1 技术简介
2.1.1 K0s
K0s可以认为是一个 Kubernetes 发行版,是一个简易、稳定且经过认证的 Kubernetes 发行版,其由云计算服务供应商Mirantis推出,该版本强调简易醒与强健性,k0s针对各种工作负载的需求,均能够满足,无论是本地端部署,还是是大规模集群部署等。2.1.2 Containerd
Containerd 是一个高度模块化的高级运行时,所有模块均可插拔,模块均以 RPC service 形式注册并调用(gRPC 或者 TTRPC)。不同插件通过声明互相依赖,由 Containerd 核心实现统一加载,使用方可以自行实现插件以实现定制化的功能。当然这种设计虽然使得 Containerd 拥有强大的跨平台、可插拔的能力,同时也带来一些缺点,模块之间功能互调必须通过 RPC 调用。注:TTRPC 是一种基于 gRPC 的裁剪版通信协议。
从官方文档中可以看出,Containerd 被定义为 “它是为其宿主机系统提供完整容器生命周期管理的守护进程,从镜像传输与存储到容器执行和监控以及低级存储等”。 正如下图所示,Containerd 逐渐成为容器管理内核。![🐧[Containerd] 深度剖析-CRI篇 - 图6](/uploads/projects/seekerzw@yaaygq/c51004e4db75580841c30c7000f6f42c.png)
2.1.3 Containerd-shim
Runtime v2 为运行时实现者引入了一套shim API,以便与 Containerd 集成。shim API 只针对容器的执行生命周期管理。其是用于剥离 Containerd 守护进程与容器进程。目前已有 shim v1 和 shim v2 两个版本;它是Containerd 中的一个插件,其通过 shim 调用低级运行时命令来启动容器。注:简单来说引入shim是允许低级运行时(如runc、youki等)在创建和运行容器之后退出, 并将shim作为容器的父进程, 而不是containerd作为父进程,是否还记得Containerd 抽象uds漏洞?
每一个 Containerd 容器都有一个相应的shim守护进程,这个守护进程会提供一个 API,Containerd 使用该 API 来管理容器基本的生命周期(启/停等),在容器中执行新的进程、调整 TTY 的大小以及与特定平台相关的其他操作。shim 还有一个作用是向 Containerd 报告容器的退出状态,在容器退出状态被 Containerd 收集之前,shim 会一直存在。这一点和僵尸进程很像,僵尸进程在被父进程回收之前会一直存在,只不过僵尸进程不会占用资源,而 shim 会占用资源。2.2 创建集群
Mirantis引入了k0sctl配套的二进制文件,它只需要对一些Linux服务器进行ssh访问,以便在这些服务器上自动安装集群。K0s是作为单个二进制文件进行分发的,除了内核之外,它不依赖于主机操作系统,不需要特定的主机操作系统发行版,也不需要额外安装软件包。该配置文件包含以下内容:
$ k0sctl init > k0sctl.yaml
可以修改上述文件,为K8s服务组件(kube-apiserver、kube-controller、kube-proxy)、网络插件(默认为Calico)和其他组件添加额外的配置选项。在目前的例子中,只是保留了默认的配置,但改变了IP地址以匹配预先提供的主机。
apiVersion: k0sctl.k0sproject.io/v1beta1kind: Clustermetadata:name: k0s-clusterspec:hosts:- ssh:address: 10.0.0.1user: rootport: 22keyPath: /Users/luc/.ssh/id_rsarole: server- ssh:address: 10.0.0.2user: rootport: 22keyPath: /Users/luc/.ssh/id_rsarole: workerk0s:version: 0.10.0
- master node: 163.172.190.5
- worker node: 163.172.190.5
$ k0sctl apply
![🐧[Containerd] 深度剖析-CRI篇 - 图7](/uploads/projects/seekerzw@yaaygq/4d28f85816a9d7a058df3b344be5e870.png)
检查集群的节点,可以发现只列出了一个节点。master节点是专门用来运行管理控制平面的,因此不允许调度Pod。
$ k0sctl kubeconfig -c k0sctl.yaml > kubeconfig$ export KUBECONFIG=$PWD/kubeconfig
$ kubectl get noNAME STATUS ROLES AGE VERSIONworker Ready <none> 5m v1.20.2-k0s1
注意:创建k0s的主要原因之一是控制平面隔离。
kubelet是运行在集群每个节点上的agent,其需要与容器运行时进行通信,以便管理容器。为此,K0s默认提供containerd运行时,当然可以配置其他的运行时,如:- Docker
- CRI-O
![🐧[Containerd] 深度剖析-CRI篇 - 图8](/uploads/projects/seekerzw@yaaygq/3062b245f28741e5ec5a43f6aceb1560.png)
![🐧[Containerd] 深度剖析-CRI篇 - 图9](/uploads/projects/seekerzw@yaaygq/3d96ebd7b1ec8268545026aaac28feff.png)
注意:下图实际docker(即moby)默认使用containerd容器运行时。
![🐧[Containerd] 深度剖析-CRI篇 - 图10](/uploads/projects/seekerzw@yaaygq/ca0cae2a3ac8a3b4385916a5fc925130.jpeg)
2.3 容器运行时
2.3.1 默认运行时
标准化的Kubernetes集群上运行一个简单的pod时,低级运行时容器默认是runc。创建的pod配置如下。通过查看工作节点上运行的进程,可以发现有多个containerd-shim-runc-v2的进程:一个用于新创建的pod,一个用于为启动的每个pod。目前有7个pod在运行。
$ cat <<EOF | kubectl apply -f -apiVersion: v1kind: Podmetadata:name: www-runcspec:containers:- image: nginx:1.18name: wwwports:- containerPort: 80EOF
逻辑关系可以简单表述如下。 kubelet → containerd → containerd-shim-runc-v2 → runc
$ kubectl get po -A | awk '{print $1" "$2}'default www-runckube-system calico-kube-controllers-5f6546844f-tw8t6kube-system calico-node-4p98gkube-system coredns-5c98d7d4d8-9z425kube-system konnectivity-agent-m4gstkube-system kube-proxy-jq6qdkube-system metrics-server-6fbcd86f7b-m8cnd
![🐧[Containerd] 深度剖析-CRI篇 - 图11](/uploads/projects/seekerzw@yaaygq/570cbd33d967d20952e3744ddbf89970.png)
2.3.2 GVisor
Google gVisor 是 Google 计算平台 (GPC) App Engine、Cloud Functions 和 CloudML 的sandbox基础。谷歌意识到在公共云基础设施中运行不受信任的应用程序的风险以及使用虚拟机沙箱应用程序的效率低下,由此开发了一个用户空间内核用来处理不受信任的应用程序。gVisor通过拦截应用程序发起的针对主机内核的系统调用,并在用户空间中通过Sentry处理这些系统调用。即使容器的恶意代码对内核进行破坏也是容器的内核,而非宿主机的内核。 简而言之,gVisor内核用Go语言编写,在用户空间运行,这个内核实现了Linux系统调用接口的很大一部分,并拦截应用程序的系统调用,从而提供了相应的保护,避免了主机内核的漏洞。gVisor组件包括一个runsc的Open Container Initiative(OCI)运行时。![🐧[Containerd] 深度剖析-CRI篇 - 图12](/uploads/projects/seekerzw@yaaygq/0d80a5503f182b77fe4b5257a15ff53a.png)
然后,在containerd配置文件中添加一些配置,以便它可以使用gVisor作为其他的运行时。
set -eURL=https://storage.googleapis.com/gvisor/releases/release/latestwget ${URL}/runsc ${URL}/runsc.sha512 \${URL}/gvisor-containerd-shim ${URL}/gvisor-containerd-shim.sha512 \${URL}/containerd-shim-runsc-v1 ${URL}/containerd-shim-runsc-v1.sha512sha512sum -c runsc.sha512 \-c gvisor-containerd-shim.sha512 \-c containerd-shim-runsc-v1.sha512rm -f *.sha512chmod a+rx runsc gvisor-containerd-shim containerd-shim-runsc-v1sudo mv runsc gvisor-containerd-shim containerd-shim-runsc-v1 /usr/local/bin
接下来,重新加载其配置。
$ cat<<EOF | sudo tee /etc/k0s/containerd.tomldisabled_plugins = ["restart"][plugins.linux]shim_debug = true[plugins.cri.containerd.runtimes.runsc]runtime_type = "io.containerd.runsc.v1"EOF
注意:如果是大规模集群,建议使用批量工具,如ansible,或者使用高级节点管理工具等 紧接着,定义一个与gVisor的runsc运行时关联的RuntimeClass。
$ kill -s SIGHUP CONTAINER_PID
然后使用这个新的RuntimeClass运行Pod。
$ cat<<EOF | kubectl apply -f -apiVersion: node.k8s.io/v1beta1kind: RuntimeClassmetadata:name: gvisorhandler: runscEOF
列出带有app=untrusted标签的Pod,可以看到pod www-gvisor运行正常。
$ cat<<EOF | kubectl apply -f -apiVersion: v1kind: Podmetadata:labels:app: untrustedname: www-gvisorspec:runtimeClassName: gvisorcontainers:- image: nginx:1.18name: wwwports:- containerPort: 80EOF
它使用gVisor/runsc,增加了一个额外的保护,因为系统调用首先由用户区内核处理。进程的调用链如下。 kubelet → containerd → containerd-shim-runsc-v1 → runsc
$ kubectl get po -l app=untrustedNAME READY STATUS RESTARTS AGEwww-gvisor 1/1 Running 0 9s
2.3.3 Kata Containers
kata container是为了解决容器安全的问题而诞生的,传统的容器是基于namespace和cgroup进行隔离,在带来轻量简洁的同时,也带来了一些安全的隐患。容器虽然提供一个与系统中的其它进程资源相隔离的执行环境,但是与宿主机系统是共享内核的,一旦容器里的应用逃逸到内核,后果不堪设想,尤其是在多租户的场景下。Kata就是在这样的背景下应运而生,kata很好的权衡了传统虚拟机的隔离性、安全性与容器的简洁、轻量。这一点和firecracker类似,都是轻量的虚拟机。但是他们的本质的区别在于:kata虽然是基于虚机,但是其表现的却跟容器是一样的,可以像使用容器一样使用kata;而firecracker虽然具备容器的轻量、极简性,但是其依然是虚机,一种比QEMU更轻量的VMM。![🐧[Containerd] 深度剖析-CRI篇 - 图13](/uploads/projects/seekerzw@yaaygq/2d30ddcb0b204661ff2f4b79c7062a23.png)
![🐧[Containerd] 深度剖析-CRI篇 - 图14](/uploads/projects/seekerzw@yaaygq/aa995f5c0626e46aacb66f32d63a2f30.png)
安装kata容器包。
$ cat /sys/module/kvm_amd/parameters/nested1
接下来,修改containerd配置文件,使其使用kata作为另外的运行时(在前面步骤中添加的runc和gVisor/runsc之上)。
$ bash -c "$(curl -fsSL https://raw.githubusercontent.com/kata-containers/tests/master/cmd/kata-manager/kata-manager.sh) install-packages"
接下来,重新加载其配置。
$ cat<<EOF | sudo tee -a /etc/k0s/containerd.toml[plugins.cri.containerd.runtimes.kata]runtime_type = "io.containerd.kata.v2"EOF
$ kill -s SIGHUP CONTAINER_PID
注意:如果是大规模集群,建议使用批量工具,如ansible,或者使用高级节点管理工具等
接下来,创建 一个”kata “运行时的RuntimeClass。然后使用这个新的RuntimeClass运行Pod。
$ cat<<EOF | kubectl apply -f -kind: RuntimeClassapiVersion: node.k8s.io/v1beta1metadata:name: katahandler: kataEOF
列出带有
$ cat<<EOF | kubectl apply -f -apiVersion: v1kind: Podmetadata:labels:app: untrustedname: www-kataspec:runtimeClassName: katacontainers:- image: nginx:1.18name: wwwports:- containerPort: 80EOF
<font style="color:rgb(51, 51, 51);">app=untrusted</font>标签的Pod,可以看到pod www-kata运行正常。
它运行在一个专用的虚拟机(通常定义为microVM)中,该虚拟机只为该容器创建,还可以看到一个qemu进程正在运行。
$ kubectl get po -l app=untrustedNAME READY STATUS RESTARTS AGEwww-gvisor 1/1 Running 0 8m1swww-kata 1/1 Running 0 3h25m
以下为相关调用链。 kubelet → containerd → containerd-shim-kata-v2 → kata
root@worker:~# ps -ef | grep qemu | awk '{print $11}'/usr/bin/qemu-vanilla-system-x86_64
参考文献https://betterprogramming.pub/kata-container-and-gvisor-with-k0s-82efbbcc240b
3 Containerd深度剖析-runtime篇
虽然容器领域的创业随着CoreOS、Docker的卖身,而逐渐归于平寂,但随着Rust语言的兴起,Firecracker、youki项目在容器领域泛起涟漪,对于云原生从业者来说,面试等场景中或多或少都会谈论到容器一些的历史与技术背景。3.1 需求简介
注: Container runtime统称为容器运行时
在Docker时代,关于容器运行时术语的定义是非常明确的,其为运行和管理容器的软件。但随着Docker涵盖的内容日益增多,以及多种容器编排工具的引入,该定义变得日益模糊了。 当你运行一个Docker容器时,一般的步骤是:- 下载镜像
- 将镜像解压成一个bundle,即将各层文件平铺到一个单一的文件系统中。
- 运行容器
![🐧[Containerd] 深度剖析-CRI篇 - 图15](/uploads/projects/seekerzw@yaaygq/db4c7e61eb61363f114fad3d111e0548.png)
3.2 低级容器运行时
低级运行时的功能有限,通常执行运行容器的低级任务。大多数开发者日常工作中不会使用到。其一般指按照 OCI 规范、能够接收可运行roofs文件系统和配置文件并运行隔离进程的实现。这种运行时只负责将进程运行在相对隔离的资源空间里,不提供存储实现和网络实现。但是其他实现可以在系统中预设好相关资源,低级容器运行时可通过 config.json 声明加载对应资源。低级运行时的特点是底层、轻量,限制也很一目了然:- 只认识 rootfs 和 config.json,没有其他镜像能力
- 不提供网络实现
- 不提供持久实现
- 无法跨平台等
低级运行时demo
通过以root方式使用Linux cgcreate、cgset、cgexec、chroot和unshare命令来实现简单容器。 首先,以busybox容器镜像作为基础,设置一个根文件系统。然后,创建一个临时目录,并将busybox解压到该目录中。紧接着创建uuid,并对内存和CPU设置限制。内存限制是以字节为单位设置的。在这里,将内存限制设置为100MB。
$ CID=$(docker create busybox)$ ROOTFS=$(mktemp -d)$ docker export $CID | tar -xf - -C $ROOTFS
例如,如果我们想把我们的容器限制在两个cpu core上,可以设定一秒钟的周期和两秒钟的配额(1s=1,000,000us),这将允许进程在一秒钟的时间内使用两个cpu core。
$ UUID=$(uuidgen)$ cgcreate -g cpu,memory:$UUID$ cgset -r memory.limit_in_bytes=100000000 $UUID$ cgset -r cpu.shares=512 $UUID
接下来在容器中执行命令。
$ cgset -r cpu.cfs_period_us=1000000 $UUID$ cgset -r cpu.cfs_quota_us=2000000 $UUID
最后,删除前面创建的cgroup和临时目录。
$ cgexec -g cpu,memory:$UUID \> unshare -uinpUrf --mount-proc \> sh -c "/bin/hostname $UUID && chroot $ROOTFS /bin/sh"/ # echo "Hello from in a container"Hello from in a container/ # exit
$ cgdelete -r -g cpu,memory:$UUID$ rm -r $ROOTFS
低级运行时demo
为了更好地理解低级容器运行时,以下列举了几个低级运行时代表,各自实现了不同的功能。runC
runC是目前使用最广泛的容器运行时。它最初是集成在Docker的内部,后来作为一个单独的工具,并以公共库的方式提取出来。 在2015 年,在 Linux 基金会的支持下有了 Open Container Initiative (OCI)(就是负责制定容器标准的组织),Docker 将自己容器格式和运行时 runC 捐给了 OCI。OCI 在此基础上制定了 2 个标准:运行时标准 Runtime Specification (runtime-spec) 和 镜像标准 Image Specification (image-spec) ,下面通过示例,简要介绍一下 runC。 首先创建根文件系统。这里我们将再次使用busybox。接下来创建一个config.json文件
$ mkdir rootfs$ docker export $(docker create busybox) | tar -xf - -C rootfs
这个命令为容器创建一个模板config.json。
$ runc spec
默认情况下,它在根文件系统位于./rootfs的目录下运行命令。
$ cat config.json{"ociVersion": "1.0.2","process": {"terminal": true,"user": {"uid": 0,"gid": 0},"args": ["sh"],"env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin","TERM=xterm"],"cwd": "/","capabilities": {...
$ sudo runc run mycontainerid/ # echo "Hello from in a container"Hello from in a container
rkt(已废弃)
rkt是一个同时具有低级和高级功能的运行时。例如,很像Docker,rkt允许你构建容器镜像,获取和管理本地存储库中的容器镜像,并通过一个命令运行它们。runV
runv 是 OCF 基于管理程序的(Hypervisor-based )运行时 Runtime.runV 兼容 OCF。作为虚拟容器运行时引擎的runV已被淘汰。runV团队与英特尔一起在OpenInfra Foundation中创建了Kata Containers项目youki
Rust是时下最流行的编程语言,而容器开发也是一个时兴的应用领域。将两者结合使用Rust来做容器开发是一个值得尝鲜的体验。youki是使用Rust的实现OCI运行时规范,类似于runc。3.3 高级容器运行时
高级运行时负责容器镜像的传输和管理,解压镜像,并传递给低级运行时来运行容器。通常情况下,高级运行时提供一个守护程序和一个API,远程应用程序可以使用它来运行容器并监控它们,它们位于低层运行时或其他高级运行时之上。 高层运行时也会提供一些看似很低级的功能。例如,管理网络命名空间,并允许容器加入另一个容器的网络命名空间。 这里有一个类似逻辑分层图,可以帮助理解这些组件是如何结合在一起工作的。![🐧[Containerd] 深度剖析-CRI篇 - 图16](/uploads/projects/seekerzw@yaaygq/5ecc969f8f5d39efb4d31890cada5658.png)
3.3.1 高级运行时代表
Docker
Docker是最早的开源容器运行时之一。它是由平台即服务的公司dotCloud开发的,用于在容器中运行用户的应用。 Docker是一个容器运行时,包含了构建、打包、共享和运行容器。Docker基于C/S架构实现,最初是由一个守护程序dockerd和docker客户端应用程序组成。守护程序提供了构建容器、管理镜像和运行容器的大部分逻辑,以及一些API。命令行客户端可以用来发送命令和从守护进程中获取信息。 它是第一个流行开来的运行时间,毫不过分的说,Docker对容器的推广做出了巨大的贡献。 Docker最初实现了高级和低级的运行时功能,但这些功能后来被分解成单独的项目,如runc和containerd,以前Docker的架构如下图所示,现有架构中,docker-containerd变成了containerd,docker-runc变成了runc。![🐧[Containerd] 深度剖析-CRI篇 - 图17](/uploads/projects/seekerzw@yaaygq/21bb26447e2f0b05010928510af5e364.png)
Containerd
containerd是从Docker中分离出来的高级运行时。containerd实现了下载镜像、管理镜像和运行镜像中的容器。当需要运行一个容器时,它会将镜像解压到一个OCI运行时bundle中,并向runc发送init以运行它。 Containerd还提供了API,可以用来与它交互。containerd的命令行客户端是ctr和nerdctl。 可以通过ctr拉取一个容器镜像。列出所有的镜像:
$ sudo ctr images pull docker.io/library/redis:latest
运行容器:
$ sudo ctr images list
列出运行容器:
$ sudo ctr container create docker.io/library/redis:latest redis
停止容器:
$ sudo ctr container list
这些命令类似于用户与Docker的互动方式。
$ sudo ctr container delete redis
rkt(已废弃)
rkt是一个同时具有低级和高级功能的运行时。例如,很像Docker,rkt允许你构建容器镜像,获取和管理本地存储库中的容器镜像,并通过一个命令运行它们。3.3.2 Kubernetes CRI
CRI在Kubernetes 1.5中引入,作为kubelet和容器运行时之间的桥梁。社区希望Kubernetes集成的高级容器运行时实现CRI。该运行时处理镜像的管理,支持Kubernetes pods,并管理容器,因此根据高级运行时的定义,支持CRI的运行时必须是一个高级运行时。低级别的运行时并不具备上述功能。
为了进一步了解CRI,可以看看整个Kubernetes架构。kubelet代表工作节点,位于Kubernetes集群的每个节点上,kubelet负责管理其节点的工作负载。当需要运行工作负载时,kubelet通过CRI与运行时进行通信。由此可以看出,CRI只是一个抽象层,允许切换不同的容器运行时。![🐧[Containerd] 深度剖析-CRI篇 - 图18](/uploads/projects/seekerzw@yaaygq/e8d0da0785a1b81641b8fcb99e2c6d67.png)
3.3.3 CRI规范
CRI定义了gRPC API,该规范定义在Kubernetes仓库中cri-api目录中。CRI定义了几个远程程序调用(RPC)和消息类型。这些RPC用于管理工作负载等内容,如 “拉取镜像”(ImageService.PullImage)、”创建pod”(RuntimeService.RunPodSandbox)、”创建容器”(RuntimeService.CreateContainer)、”启动容器”(RuntimeService.StartContainer)、”停止容器”(RuntimeService.StopContainer)等操作。 例如,通过CRI启动一个新的Pod(篇幅有限,进行了一些简化工作)。RunPodSandbox和CreateContainer RPCs在其响应中返回ID,在后续请求中使用。可以直接使用crictl工具与CRI运行时交互,可以用它来调试和测试CRI的相关实现。
ImageService.PullImage({image: "image1"})ImageService.PullImage({image: "image2"})podID = RuntimeService.RunPodSandbox({name: "mypod"})id1 = RuntimeService.CreateContainer({pod: podID,name: "container1",image: "image1",})id2 = RuntimeService.CreateContainer({pod: podID,name: "container2",image: "image2",})RuntimeService.StartContainer({id: id1})RuntimeService.StartContainer({id: id2})
或者通过命令行指定:
cat <<EOF | sudo tee /etc/crictl.yamlruntime-endpoint: unix:///run/containerd/containerd.sockEOF
关于crictl的使用参见官网。
crictl --runtime-endpoint unix:///run/containerd/containerd.sock …
3.3.4 支持CRI的运行时
Containerd
containerd应该是目前最流行的CRI运行时。它以插件的方式实现CRI,默认是启用的。它默认在unix套接字上监听消息。 从1.2版本开始,它通过 runtime handler来支持多种低级运行时。运行时处理程序是通过CRI中的字段传递,根据该运行时处理程序,containerd运行shim的应用程序来启动容器。这可以用来运行 runc及其他的低级运行时的容器,如 gVisor、Kata Containers等。在Kubernetes API中通过RuntimeClass进行运行时配置。 下图是Containerd的发展史。![🐧[Containerd] 深度剖析-CRI篇 - 图19](/uploads/projects/seekerzw@yaaygq/888fd6013f3a718ec754db1a9e13e7c3.png)
![🐧[Containerd] 深度剖析-CRI篇 - 图20](/uploads/projects/seekerzw@yaaygq/5bc42c8112b6c457bae4e798724b5b14.png)
Docker
docker-shim是K8s社区第一个被开发的,作为kubelet和Docker之间的shim。随着Docker将其许多功能分解到containerd中,现在通过containerd支持CRI。当现代版本的Docker被安装时,containerd也一起被安装,CRI直接与containerd对话,随着docker-shim正式废弃,是时候考虑相关迁移的工作了,K8s在这方面做了大量的工作,具体可参看官方文档。CRI-O
cri-o是一个轻量级的CRI运行时,它支持OCI,并提供镜像的管理、容器进程管理、监控日志及资源隔离等工作。 cri-o的通信地址默认是在<font style="color:rgb(51, 51, 51);">/var/run/crio/crio.sock</font>。
![🐧[Containerd] 深度剖析-CRI篇 - 图21](/uploads/projects/seekerzw@yaaygq/0dc2d09ba996ff6a9a08628b7262a998.png)
![🐧[Containerd] 深度剖析-CRI篇 - 图22](/uploads/projects/seekerzw@yaaygq/f2f421041254cdba49698970092b29c2.png)
![🐧[Containerd] 深度剖析-CRI篇 - 图23](/uploads/projects/seekerzw@yaaygq/18184fca222caf0427cb80974e3c88f0.png)
参考文献
