---
title: Docker Desktop 与本地环境边界收缩
date: '2018-01-06 13:54:28'
draft: false
summary: 把 Kubernetes 直接收进 Docker Desktop 后，本地容器开发环境里的很多碎片配置被顺手消掉了。
slug: docker-desktop-builtin-kubernetes
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/FD6jPkYko
tags:
- docker
- kubernetes
- minikube
- developer-experience
topics:
- software-engineering
type: post
---

`Docker Desktop` 把 `Kubernetes` 内置进去之后，我觉得它真正有价值的地方，不只是“又少装了一个工具”，而是它在尝试收缩本地容器开发环境里原本很碎的边界。

过去在本地玩 `Kubernetes`，常见路径往往是：

- 宿主机上跑 `Docker`
- 再额外装一个 `minikube`
- `minikube` 里再带自己那套 VM 和 Docker 运行环境

这样最大的麻烦不是组件多，而是环境割裂。

比如 `minikube` 里内置的 Docker 和宿主机上的 Docker 不是一个实例，镜像也不共享。你本地刚 build 完一个镜像，结果集群里还看不到，还要再想办法同步进去。这个体验非常别扭。

而 `Docker Desktop` 内置 `Kubernetes` 后，等于把原来分散在 `minikube`、`kubeadm` 初始化脚本和本地 Docker VM 之间的一部分逻辑，尽量合并到了同一个宿主环境里。

这意味着：

- 镜像共享更自然
- 本地调试链路更短
- 开发者不需要同时维护两套互相割裂的容器世界

当然，它并没有因此让问题彻底消失。比如安装和初始化链路在当时依然受网络环境影响，版本支持也并不总是最新。

但方向上我觉得是对的。

因为本地 `Kubernetes` 环境真正需要解决的，不只是“能跑起来”，而是能不能尽量减少心智切换，让开发者感觉自己面对的是一个统一环境，而不是多个松散拼起来的实验套件。

从这个角度看，内置 `Kubernetes` 的价值，其实是一种本地基础设施整合能力。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4193190854998464-1.jpg)

![](./weibo-4193190854998464-2.jpg)
<!-- WEIBO_MEDIA_END -->