从Docker到k8s：容器编排的演进

近年来，容器技术的发展迅猛，为应用的构建、交付和运维带来了很多便利。Docker作为最受欢迎的容器引擎之一，为容器技术的普及起到了重要的推动作用。然而，随着容器技术的不断演进，我们逐渐发现Docker并不是最终的解决方案。在新版k8s中，不再直接支持Docker作为容器运行时，而是通过CRI（Container Runtime Interface）与容器运行时进行交互。本文将介绍新版k8s不再支持Docker的背景和原因，并给出相应的代码示例。

为什么不再支持Docker？

Docker在容器领域的崛起，使得应用的打包、分发和运行变得更加简单和可靠。然而，Docker也存在一些问题，主要包括：

  1. 安全性：Docker容器运行时与宿主机共享内核，容器之间的隔离性有限。这使得一旦一个容器被攻破，攻击者可能会访问宿主机上的其他容器和敏感数据。

  2. 性能：Docker容器运行时在处理网络和存储时存在一定的性能损耗。在大规模容器集群中，性能问题可能会影响应用的稳定性和可扩展性。

  3. 复杂性：Docker的架构相对复杂，包括守护进程、镜像仓库、网络和存储驱动等。这增加了运维的复杂性和学习成本。

为了解决这些问题，k8s引入了CRI作为容器运行时接口的标准，将容器运行时与k8s解耦，使得k8s能够与多种容器运行时进行交互，如containerd、CRI-O等。CRI通过gRPC接口与容器运行时进行通信，提供了更好的安全性、性能和灵活性。

使用CRI示例

下面是一个使用CRI创建和管理容器的示例代码：

import (
    "context"
    "fmt"
    "github.com/containerd/containerd"
    "github.com/containerd/containerd/namespaces"
)

func main() {
    // 连接到containerd
    client, err := containerd.New("/run/containerd/containerd.sock")
    if err != nil {
        panic(err)
    }
    defer client.Close()

    // 创建一个容器
    container, err := client.NewContainer(
        context.Background(),
        "my-container",
        containerd.WithImage("my-image"),
    )
    if err != nil {
        panic(err)
    }
    defer container.Delete(context.Background())

    // 启动容器
    task, err := container.NewTask(
        context.Background(),
        cio.NewCreator(cio.WithStdio),
    )
    if err != nil {
        panic(err)
    }
    defer task.Delete(context.Background())

    // 等待容器退出
    statusC, err := task.Wait(context.Background())
    if err != nil {
        panic(err)
    }

    // 打印容器退出状态
    status := <-statusC
    fmt.Printf("Container exited with status %d\n", status.ExitCode)
}

上述代码使用containerd作为容器运行时，通过CRI与k8s进行交互。我们可以看到，与Docker相比，使用CRI创建和管理容器的代码更加简洁和清晰。

状态图

下面是一个使用mermaid语法绘制的状态图，展示了使用CRI创建和管理容器的过程。

stateDiagram
    [*] --> Creating
    Creating --> Running
    Running --> Stopped
    Stopped --> [*]

上述状态图清晰地展示了容器的生命周期，从创建到启动，最后到停止和销毁。