Question

我很难用k8构建工作流程，其中包括：

为多个微服务 monorepo
单一命令启动所有这些命令并能够启动本地开发
拥有docker-like在其他未安装k8的计算机上安装整个基础架构的经验（用于本地开发）1。git pull 2. k8s start，3。等待，4。 ping localhost:3000将成为这里的目标。
能够将本地文件中的更改立即应用到服务而无需重建图像等（类似于我认为的泊坞窗卷）
拥有模块化配置文件，其中有一个根配置文件用于引用服务较小配置的基础架构

我正在努力寻找一些没有运气的构建这样的系统的例子或指南。

我是否遗漏了一些关于k8s设计的重要信息，这让我找到了一些不太可能的k8s？

为什么我认为这个问题不应该被关闭

有许多没有开发人员经验的开发人员尝试使用微服务，并且我发现缺乏关于此类（并且非常常见）用例的实用指南
关于k8s的快速反馈循环，没有关于平稳本地开发体验的明确指南。
虽然它基于意见，但我发现这个问题更侧重于导致这种开发人员体验的一般方向，而不是确切的步骤。

我甚至不确定（而且我试图找出）是否被视为专业开发人员的良好做法。我不知道有多大基础设施（数十或数百个微服务）被管理。是否可以在一台机器上运行它们？是否需要？

Answer 1

我建造的东西类似于你之前提出的问题。我手动运行了hyperkube，这几乎不值得推荐，但却为本地开发做了诀窍。在我的情况下，这一切都在Vagrant中运行，以确保团队的一致性。

docker run -d --name=kubelet \
        --volume=/:/rootfs:ro \
        --volume=/sys:/sys:ro \
        --volume=/var/lib/docker/:/var/lib/docker:rw \
        --volume=/var/lib/kubelet/:/var/lib/kubelet:slave \
        --volume=/var/run:/var/run:rw \
        --net=host \
        --pid=host \
        --privileged \
        --restart=always \
        gcr.io/google_containers/hyperkube-${ARCH}:${K8S_VERSION} \
        /hyperkube kubelet \
            --containerized \
            --hostname-override=127.0.0.1 \
            --api-servers=http://localhost:8080 \
            --cluster-dns=10.0.0.10 \
            --cluster-domain=cluster.local \
            --allow-privileged --v=2 \
            --image-gc-high-threshold=50 \
            --image-gc-low-threshold=40 \
            --kube-api-qps 1000 --kube-api-burst=2000 \
            --pod-manifest-path=/etc/kubernetes/manifests

除此之外，我还构建了可以使用YAML mustache模板的脚本，这些模板可以识别部署的位置。当在本地部署它时，每个pod都将源代码作为卷安装，因此我可以自动重新加载它。

相同的脚本能够部署到生产，因为它都基于胡子模板。我甚至有多个配置文件可以为不同的环境应用不同的模板值。

构建脚本将准备YAML模板，构建它需要构建的任何图像，应用于Kubernetes，然后从那里自动重新加载。这是一个半不错的用户体验。我的主要问题是文件更新时的迟缓，因为它在Vagrant里面的Docker中运行。没有文件共享类型可以为客户端和服务器提供良好的性能和允许文件监视（inotify不能与大多数文件共享类型一起使用，以及NFS / SMB IDE的速度很慢。）

这是我的第一次Kubernetes体验，所以我怀疑它是推荐的方式＆＃34;，但它有效。涉及到很多脚本，所以今天可能有更好的方法来实现这一目标。

创建monorepo kubernetes基础设施的好方法是什么？

1 个答案: