在之前一篇体验一把使用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思路，可以实现对多集群的应用版本管理.

现在业务使用的kong做为api gateway, 最近碰到一个的kong error超时及重试的问题，记录下排查过程

kong中提供了两种最基本认证方式,即用户密码认证， basic-auth及basic-auth-api，这两种方式非常好理解，使用的场景类似

basic-auth的认证方式是直接验证用户名密码

而basic-auth-api会将提交的用户名密码到指定的api接口认证，比如统一认证服务

basic auth可以为Route或者Service添加简单的用户名密码认证

最近有一台物理机间歇性的发生重启, 本以为是偶发事件就没多在意，今天又给重启了, 因此决定探探究竟

最近有一台物理机间歇性的发生重启, 本以为是偶发事件就没多在意，今天又给重启了, 因此决定探探究竟