はじめに
本記事は Alibaba CloudのkubernetesやServerless製品（SAEなど）でサービス立ち上げてみよう by Alibaba Cloud Advent Calendar 2023 の2日目が空いてたので穴埋め記事です。
私は普段Azure中心で、主にはAzure Kubernetes Service（AKS）を触っています。
今回アドベントカレンダーでプレゼントキャンペーンを開催していたので、Alibaba Cloudを初めて触ってみました。
この記事では、AKSユーザーから見て Alibaba Cloud Container Service for Kubernetes (ACK) のよかったポイント・特徴的なポイントを紹介します。
ここがよかった
マニフェストいらずでらくらくデプロイ
これがACKの特徴的な部分だと思うのですが、コンソールからポチポチクリックしていくだけでコンテナをデプロイできます。
ワークロードのページの右上から イメージによる作成 をクリックします。
コンテナデプロイのウィザードが表示されるので、必要なパラメータを入力していきます。
最初の画面ではKubernetesリソースの名前を付け、レプリカ数とデプロイの種類（Replicaset, Deployment, Daemonset, Job, CronJob）を選択します。
次の画面ではコンテナの情報を入力していきます。
イメージ名やイメージバージョン（タグ）の入力箇所では、同アカウントのContainer Registry内のイメージを検索して設定できます。
そのほかにポートや各プローブ、コンテナで実行するコマンドやストレージマウントなどを同画面で設定できます。
更に次の画面では上級として、HPAやPodスケジューリング周りの設定、サービスやIngressの作成を行うことができます。
必要な情報を入力して 次 へと進めていくと、入力した情報を基にPodが起動します。
以下はDeploymentとしてレプリカ数2の nginx Podを起動させた例です。
このように YAMLのマニフェストを書くことなく、コンソール操作のみでアプリケーションをデプロイできる というのは大きな特色でしょう。
Kubernetes初心者の方でも比較的とっつきやすい、よい機能だと思います。
タイムゾーン設定が容易
Kubernetesクラスターを作成する画面の途中で、ひっそりと タイムゾーン の設定が存在します。
また、先に紹介したコンテナをデプロイする画面では、タイムゾーンの同期 という設定があります。
この2つの設定を利用することで、アプリケーションをJSTなどのタイムゾーンで稼働させることが容易にできます。
ログを表示させると + 0900 とJSTで表示されていることが確認できます。
他のクラウドのKubernetsサービスだと、タイムゾーンをこのレベルの簡易さで設定できるのはあまり見ない気がします。
AKSを使う際はUTCを前提とすることが殆どですが、このぐらい簡単に設定できるのであればJSTを利用してもいいかも…と思える機能でした。
Kubernetesバージョンの利用可能期間が長い
ACKで利用可能なKubernetesバージョンについてのドキュメントを見てみましょう。
https://www.alibabacloud.com/help/en/ack/product-overview/support-for-kubernetes-versions
驚いたことに、v1.26が 2025年4月まで使える という表記になっています。
Kubernetes公式のリリースページを見るとv1.26系のEOLは 2024年2月28日となっているため、それよりさらに1年以上長いということとなります。
https://kubernetes.io/releases/
Kubernetesバージョンアップのライフサイクルの短さに疲弊している方も多いでしょうから、長く使えるのであれば運用面で有利になるシーンもあることでしょう。
（ところで、公式EOL後のセキュリティアップデートとかは提供されるんでしょうか…）
アップグレード画面の親切さ
上記のスクリーンショットからもわかるようにKubernetesのマイナーバージョンは現状一つ飛ばしで提供されています。
2023/12現在の選択肢としては 1.24, 1.26, 1.28 の3種類のバージョンが選択可能です。
ですので、バージョンアップも1つ飛ばしで実施することとなります。
バージョンを1つ飛ばしにすることで利用しているAPIの変化などが不安になりますが、アップグレード時には 事前チェック を実行し影響を確認することができます。
Container Intelligence ServiceのUpgrade Checkの画面でチェック結果を確認できます。試しにやってみた限りでは何も検知されませんでしたが、利用しているAPIが廃止されていないかをチェックしてくれているようです。
事前チェック機能と、その結果の表示がわかりやすい形で行われるのは親切だと感じました。
よくないところ
よいところばかり挙げていても宣伝っぽくなってしまうので、触ってみた範囲で「アレ？」と思ったことも挙げておきましょう。
コンソールの表示と状態がイマイチ
クラスターの作成直後にPodがぜんぜん起動しておらず、原因を調べているとノードが1台も起動していませんでした。
ノードの数が 0/1 (実際のノード数 / 予想されるノード数) と表示されてはいるものの、正常に起動できていないのであればステータスは 有効 ではなく、何か異常を示す表示だとわかりやすいのに、と感じました。
ノードの展開がセキュリティ機能で止められた
上記のノードが起動していない原因を調べてみると、スケーリングアクティビティに以下のメッセージが記録されていました。
組み込みのリスク管理システム（Aliyun RiskControl system）によって拒否されていたようです。
私の設定が不足していた、というのはもちろんあり得るのですが、作成時にいきなり拒否されてしまうのはユーザー体験としてあまりよくないかと思いました。
なお、この事象はいろいろ調べた結果、支払い手段として登録した内容に不備があったようで、身分証の写真などをアップロードし承認をもらうことで使えるようになりました。
おわりに
はじめてAlibaba Cloudを触ってみましたが、ACKのKubernetes固有の設定はコンソールで設定できる部分が多く、親切に作られていると感じました。
一方、Alibaba Cloud全体的な部分でいうと、まだまだ粗削りな感想も抱きました。
以下は東京リージョンにプロビジョニングしたノードの一覧画面ですが、ゾーンの部分の表記が 东京 可用区A と中国語表記のままとなっています。
表示上の問題だけなので特に問題はないのですが、ローカライズが不十分な感覚は否めません。
ということで、感想としてはクセはありながらも面白いサービスだと感じました。クラウドベンダー間で競争を進めていって、それぞれ尖った機能を実装していってほしいですね。