索引

• 試行錯誤の検証段階

 

• どうやってkubernetesの理解に至ったか？

 

• 導入方針

 

• 導入範囲

 

• Azureマネージドサービスとの連携

 

kubernetes化への既存環境の問題

◆试错的验证阶段

为了真正理解，我决定先创建一个Kubernetes集群，并对其进行各种操作。所以，我在Azure Kubernetes Service上创建了一个用于测试的集群。
在这个阶段，我考虑了以下验证场景。

• MySQLは開発環境に影響を与えないように、kubernetesクラスタ内部にEmptyDir{}で簡易MySQL Podを作って対処。

 

• Redis Cahceもkubernetesクラスタ内部にEmptyDir{}で簡易Redisを作って対処。

 

QueueなどはAzureストレージエミュレーターPodを作成して対処。

我尝试将本地测试环境直接部署到Kubernetes上进行测试，但是由于意料之外的困难，我决定放弃这个尝试。

警示

尽快亲自输入命令并进行实际操作。一本书在出版时就已经含有过时的信息了。最好建立一个本地PC或云上的一次性Kubernetes集群，尽情地进行实验和调试。

◆我是如何理解Kubernetes的？

也许目前来看，我认为使用Kubernetes的全部功能可能只掌握了一半不到…
总之，如果能够掌握以下功能，至少可以做到最基本的运营。

• kubernetesクラスタ。

 

• AzureがAKSクラスタで全部面倒見てくれます。GUIでささっと作成。クラウドは便利。クラスタ構築の作業についてとりあえず学習コストは抑えられます。

Docker buildとかpushとかpullとか。Dockerfileの書き方。
これは以前の会社からたくさん作業していたので問題ありませんでした。このやり方を知らない人は結構苦労すると思います。特にレジストリにpushする方法が複雑なので慣れるのに時間がかかるかな。

docker-composeでデプロイ(=オーケーストレーション)する仕組みの理解
初体験だったのですが、docker-compose.yamlを見てだいたい想像して理解できました。未だにdocker-composeの勉強は改まってしたことがありません。

kubernetesのマニフェストファイル=yamlの作成。
既存システムであるdocker-compose.yamlから想像して脳内変換して１種類づつ作成していきました。
事前に本で勉強していたので、１つpod作成するのにも必ずDeploymentでtemplate定義していきました。セオリーを本で勉強していたので、この点は苦労せずに移行作業することができました。
ただ最初は１つのpodに全コンテナを詰め込んでいたのが勘違いで、マイクロサービス的に各Serviceに分割していく設計変更作業が発生します。

◆引入政策

• helmやkustomizeなどのツールは使用しない。既存メンバーの学習コストを減らすため。

 

既存ソースコードはできるだけ変更しない。全てを作り変えているといくら時間があっても足りません。

类似helm和kustomize等工具

helm一直以来已经成为Kubernetes的标准包管理器。

• cert-managerはAzureアプリケーションゲートウェイの関係でLet’s Encryptの完全自動化が困難。

helm-ingressは、これもまたアプリケーションゲートウェイの関係でL7ゲートウェイとしては不採用。

在Azure中，helm这个工具几乎没有太多的使用场景。因为已经很辛苦教会团队成员如何使用Kubernetes的命令”kubectl”，所以我们不想增加学习成本更高的额外工具。

我非常为模板化而烦恼。虽然我知道Helm模板和Kustomize功能强大，但它们是非常复杂的工具，考虑到需要从零开始学习并向团队成员传授这些知识，我感到非常沮丧。因为我只需要一个简单的功能，即在Kubernetes的yaml文件中嵌入变量，所以我通过改进readline包中的envsubst工具来实现。如果有机会，我会在后面详细介绍它的使用方法。

关于源代码的修改

幸運的是，我們是一家先進技術公司，在原本已經使用docker-compose結合多個Docker容器提供服務，因此不需要對Linux服務器進行容器化的工作。如果從頭開始進行容器化工作，一個人也不能在幾個月內完成遷移工作。
然而，最初我們誤解了在docker-compose中的所有容器都應該放在kubernetes的一個Pod中，因此後來為了進行類似微服務的結構變更而苦惱。雖然修改源代碼是最快的方法，但是對於臨時遷移環境來說，源代碼修改相當麻煩且耗時，最終我們通過使用基礎設施配置技巧來避免修改大部分代碼。

◆引入范围

仅仅是将系统的一部分迁移到Kubernetes，以下资源不包括在内。

• MySQL -> クラウドのマネージドMySQLを使用。

 

• Redis -> クラウドのマネージドRedis Cacheを使用。

 

• CPUコア数十個やメモリ数十Gバイトを使用する重いバッチ処理 -> Function/Batchなどのクラウドの仕組みで別に構築。

 

一部のドローン管理サーバ -> コンテナ化が困難な事情があり、ほんのわずかですがVirtual Machineが残っています。

在很多書籍中都有關於使用Kubernetes構建MySQL的主/從負載平衡的示例，但這只是徒增麻煩，並不實用。我認為直接利用雲端的托管服務更好。

与Azure托管服务的集成

• Azure MySQLとの連携は不思議と問題なし。

 

Azure Redis Cacheとの連携はegressを利用しないとできない。

Azure MySQL – Azure MySQL

为什么可以在托管的MySQL上连接而无需通过防火墙进行授权？很奇怪。难道只有AKS集群之间才是特殊情况吗？很害怕因此可能突然被阻断通信。

Azure Redis Cache: Azure 云缓存服务

在处理接收Kubernetes集群内部Pod的连接的方法上发愁了很久，因为无论如何我都解决不了这个问题，所以无可奈何地向Microsoft技术支持求助。
结果发现如果不使用这项技术，就无法与Redis Cache进行协作。
在Azure Kubernetes Service (AKS)中，使用静态公共IP地址作为出口流量。
虽然我也调查和验证了RBAC (Role Based Access Control)，但它很复杂，AKS集群的出站流量可以固定为特定IP地址，因此只需在Redis Cache防火墙中允许这个IP即可进行协作。

◆现有环境向Kubernetes化的问题

• セッションとキャッシュをローカル管理していてスケールできるプログラム構成になっていなかった。

 

• DBのmigrationを移行し忘れて後ほど大変なことに。k8sのどこかのコンテナでdocker exec db migrationすればいいのですが、なにしろpod名はランダムでしかもdeploy後状態のコンテナでexecしなければいけないのでかなり苦労しました。kubectl waitはたいして役に立たない機能でした。

 

その他docker-composeを起動するためにいろいろAzureのリソース作成で冪等性を保っていたのですが、k8sになって定期実行するjob/cronjobがリソースもクリーンナップしてくれず非常につかいづらく苦労させられました。

下一次

下一次将讨论令人意想不到的组件拆分问题。