Z.S.K.'s Records

k8s默认的调度器无法更好地实现对pod的All or Nothing调度能力， 在HPC或者分布式训练场景中，批处理能力对资源的使用率尤为重要.

之前进行了kind实践,可以很方便地快速组件在k8s中的验证，今天发现一款由rancher开源的相同工具, k3d，也是非常的牛逼，照样也实践一把

最近因机房网段调整，影响到一个kubernetes集群中的一个master节点，在更换该master节点ip的时候，出现了有关证书的问题，特此记录一下

看到一篇关于kubectl运行的机制，觉得写得非常不错，图文并茂很形象，就翻译成了中文记录一下，原文地址: https://erkanerol.github.io/post/how-kubectl-exec-works/

在之前一篇体验一把使用argocd对多k8s集群进行gitops的实践，在团队使用过程中会发现，argocd的sync状态跟app health状态是两个步骤，经常出现资源同步成功了但是deployment在k8s一起起不来，在argocd app status 一直都是Processing,如何处理这种情况呢? argocd如何做 resource check,有没有必要引用notification机制

再见, 2020

2021, 再见

前几天一个开发同学跑过来跟我说，在自动发布一个应用到k8s集群中时，会出现发布成功，但是容器中的配置文件还是旧配置文件的情况，让我看看原因.第一时间我觉得不可能，但是一细想，好像是有可能发生, 立马在我脑海中出现一个疑问:

使用了这么多年的k8s, kubectl apply -f <directory>时，目录下多个资源文件的apply顺序到底是什么?

相信在使用k8s的过程中，对于各种资源的操作一定是最多的，社区包括kubernetes本身出了多种模板生成工具，比如helm, kustomize这两种是最常用的，本人也一直在用，但有的场景依然会觉得这两个工具相对较重，helm使用的是gotemplate，而kustomize则又依赖于kubectl，两者都有一定的学习成本且没有交互能力，最近在做的一个小需求是: 如何快速地让开发同学以最简单的方式根据提供的模板生成部署文件，github上发现了个boilr的工具，虽然工具老了点，但是足够地小，功能足够简单，重要的是有交互功能，比较贴合需求

CI阶段使用的镜像size要尽可能地小，这样在CI pull时使用的时间也会相应的短，所以有些base镜像都是基于alpine编译出来的

今天在alpine的base镜像中使用mongoimport时，提示了not fuond的奇怪问题，记录一下解决过程

运维中经常会存在多套的环境，开发、测试、stagging、prod等，这么多的环境，对于开发同学，如何通过一次部署多环境上线，打通开发与测试间的gap，而对于运维同学来说，则关心如何保障环境之间应用版本一致，而argoCD就是这样一个工具，配合GitOps思路，可以实现对多集群的应用版本管理.