公有云在调用云产品接口的时候通常需要 secretId 和 secretKey 。而 Kubernetes 里面有一类对象叫做 secret ，所以我在想，这两块内容能不能结合起来。
当公有云管理员创建子账户的时候，这两部分信息会自动注入到相应 Kubernetes 的关联 namespace 的 secret 中，这样用户连这部分信息都不需要保存，只需要上传自己的容器镜像，之后CD会自动挂载相应的 serviceaccount ，底层公有云以统一的形式加载这部分配置。
从结果上看，
- 省略了运维设定生产配置这一毫无技术含量的工作
- 屏蔽了业务开发对线上配置的染指
最终完美实现了自动化DevOps。
不过这么做有一个前提——那就是假定 Kubernetes 作为整个公有云的第一入口，公有云要自己打通自身权限控制和 Kubernetes 之间的连接。
Public clouds usually need secretId and secretKey when calling cloud product APIs. And in Kubernetes, there’s a type of object called secret, so I’m thinking, can these two be combined?
When public cloud administrators create sub-accounts, this information is automatically injected into the corresponding Kubernetes associated namespace’s secret, so users don’t even need to save this information. They just need to upload their own container images, and then CD will automatically mount the corresponding serviceaccount. The underlying public cloud loads this configuration in a unified form.
From the result:
- Omitted the non-technical work of operations setting production configurations
- Shielded business development from meddling with online configurations
Finally achieving automated DevOps perfectly.
However, doing this has a prerequisite—that is, assuming Kubernetes as the first entry point of the entire public cloud, the public cloud needs to connect its own permission control with Kubernetes.
パブリッククラウドがクラウド製品のインターフェースを呼び出すとき、通常secretIdとsecretKeyが必要です。そしてKubernetesにはsecretというオブジェクトタイプがあるので、これら2つを組み合わせることができるか考えています。
パブリッククラウド管理者がサブアカウントを作成するとき、この情報は対応するKubernetesの関連namespaceのsecretに自動的に注入されるため、ユーザーはこの情報を保存する必要さえありません。自分のコンテナイメージをアップロードするだけで、CDが対応するserviceaccountを自動的にマウントします。基盤となるパブリッククラウドは、この設定を統一された形式で読み込みます。
結果から：
- 運用が本番設定を設定するという技術的でない作業を省略
- ビジネス開発がオンライン設定に干渉することを遮断
最終的に自動化されたDevOpsを完璧に実現。
ただし、これを行うには前提条件があります—つまり、Kubernetesをパブリッククラウド全体の最初のエントリーポイントとして想定し、パブリッククラウドは独自の権限制御をKubernetesと接続する必要があります。
Публичные облака обычно нуждаются в secretId и secretKey при вызове API продуктов облака. А в Kubernetes есть тип объекта, называемый secret, поэтому я думаю, можно ли объединить эти два?
Когда администраторы публичного облака создают подучётные записи, эта информация автоматически внедряется в соответствующий secret связанного namespace в Kubernetes, поэтому пользователям даже не нужно сохранять эту информацию. Им просто нужно загрузить свои собственные образы контейнеров, а затем CD автоматически подключит соответствующий serviceaccount. Базовое публичное облако загружает эту конфигурацию в единой форме.
С точки зрения результата:
- Исключена нетворческая работа операций по настройке производственных конфигураций
- Защищена бизнес-разработка от вмешательства в онлайн-конфигурации
В конечном итоге идеально достигается автоматизированный DevOps.
Однако для этого есть предварительное условие—то есть, предполагая Kubernetes как первую точку входа всего публичного облака, публичное облако должно соединить свой собственный контроль доступа с Kubernetes.
💬 讨论 / Discussion
对这篇文章有想法？欢迎在 GitHub 上发起讨论。
Have thoughts on this post? Start a discussion on GitHub.