Kubernetes on nnasaki のブログ

Kubernetes NGINX Ingress Controller v1.0.0 で 404 エラーになる問題の対処

Tue, 28 Sep 2021 12:09:28 +0900

問題

AKS 上で NGINX Ingress Controller を使っていて、 v1.0.0 にアップグレードしたらサイトが404エラーになってしまった。

404

解析

ログを見ると以下エラーが出ていた。ingress class のバリデートでエラーが出たから Ingress を無効化したらしい。

I0927 15:01:58.774073 6 store.go:361] “Ignoring ingress because of error while validating ingress class” ingress=“mvp-staging/sitecore-ingress” error=“ingress does not contain a valid IngressClass”

エラーログ

結構重要なログだと思うので Info じゃなくて、 Error 以上で出してほしい。。。

原因

NGINX Ingress Controller v1.0.0 から ingressClass オブジェクトが必須となったため。

対処

annotations に kubernetes.io/ingress.class: "nginx" を追加。

対処例

本来であれば ingressClass オブジェクトを追加するほうが良いらしいが、ひとまずこれで動く。

本問題とは別だが、対処例の apiVersion も networking.k8s.io/v1 とするのが適切。

Kubernetes v1.12 を Azure で動かしてみた

Thu, 11 Oct 2018 07:00:00 +0900

Kubernetes v1.12 が 2018/9/27 にリリースされました

kubernetes.io

今回のリリースでは Azure の VMSS(Virtual Machine Scale Sets) の対応がされました。これにより今までより早くノードが展開できることと、OSイメージによるノードの管理ができることが期待できます。

リリースの詳細はこちらの記事を参照してください。

kubernetes.io

記事に書いてあるとおり、ACS(Azure Container Service) Engine ではすでに使えるようになっています。

AKSの対応はまだですが、AKS の Service Level Objective (SLO) によるとマイナーバージョンアップは30日以内に対応するとあるので、今月末には使えるようになると思われます。

SLO の詳細はこちらの記事を参照してください。

docs.microsoft.com

ACS Engine で Kubernetes v1.12 を早速試してみた

ACS Engine の作成方法などは後回しにして、結果から書きます。

エージェントノードの展開は2分後半から4分前半で完了

検証環境はSouthEastAsiaで行いました。次の結果です。

変更前ノード数変更後ノード数デプロイ時間(mm:ss)

2
5
02:17

5
30
03:54

5
30
04:08

1
30
04:16

30
5
01:47

30
1
02:52

30
1
02:18

ノード数を増やす操作が少数の場合が2分台、30台ほどで4分台という感じです。ノード数を減らす操作は1分〜2分というところです。

十分高速かなと思います。

検証方法

下記サイトを参照して行いました。詳細を書こうと思ったんですが力尽きました。。。また別の機会に書きたいと思います。

JAPAN CONTAINER DAYS V18.12に登壇します

Mon, 01 Oct 2018 07:30:00 +0900

containerdays.jp

medium.com

なんとCFPが通りまして、JAPAN CONTAINER DAYS V18.12に登壇させていただけることになりました。嬉しい限りで本当に皆さんのおかげだなと思います。CFPの内容は次の通りです。

タイトル

Jenkins x Kubernetesが簡単だと思ったら大変だった話

概要

昨今、コンテナやkubernetesに対応したCI/CDツールはたくさんありますが、古くからあるJenkinsも当然対応しています。今回はプロダクション環境で実際に使用した経験から、Dockerビルドの苦労話や、Declarative Pipelineでコード化することでいわゆる「Jenkinsおじさん問題」を解決したことをお話しします。

また、Jenkinsを実際運用するにあたって、パブリッククラウドの比較や連携方法も合わせてお話しします。

なぜ応募したか？

理由は２つあると考えました。

JAPAN CONTAINER DAYSはベンダー主催ではない公平な場であり、規模も自分にとってはde:code以来の大きさだと思いますので、自分の実力を試したいという気持ちがありました。なので、1つ目の理由は誰かのためというよりは自分のためですね。

私はMicrosoft AzureのMVPなので、普段はMicrosoft系のコミュニティに参加することが多いです。コミュニティは「常連さん」みたいな感じで知り合いも多く、楽しいですし、とても居心地が良いです。しかし、そのままでは結局「内輪ウケ」にとどまってしまうと思い、Microsoft系以外のコミュニティに参加することがとても大事だと常々考えています。これはなにも突然思いついたことではなく、過去にも様々なコミュニティに参加させていただきました。

つまり、もう一つの理由はMicrosoft系ではないコミュニティに参加することで、Microsoft Azureを普段リーチできない層に訴えかけることができる。と考えています。

なにを伝えたいか？

今回はAzure色はほとんどなく、CI/CDの考え方。kubernetesとどう連携させるか？その際ハマるポイントはどこか？という点をお伝えして、皆様が実際に構築・運用する際のヒントを持ち帰っていてだければと思っています。

CFPに書いていたパブリッククラウドの比較については、主題から離れてぼやけてしまうのと、４０分にしてはちょっと盛り込みすぎ感がありますので、セッション構成上もしかしたら削ってしまうかもしれません。すみません。たとえ削ったとしても、それはそれでまた別な機会にお話させていただければと思います。

まとめ

12月は皆様にお会いできることを楽しみにしています。どうぞよろしくおねがいします！

申込みはこちらから！

eventregist.com

ちょっとだけ宣伝

Test Driven Development Boot Camp(TDDBC) 、テスト駆動開発のブートキャンプを10/20(土)に仙台で行います。気づいたら今年で8回目で震災後から毎年開催し、毎年TDD の伝道師、和田卓人(@t_wada)さんに来ていただいています。

仙台の方も、遠方の方も是非お越しください。

tddbc.connpass.com

コンテナ管理はどれを選ぶべき？Azure Container Service で使用出来る Docker Swarm、Mesosphere DC/OS、 Kubernetes の3つを比較してみた。

Thu, 11 May 2017 06:00:00 +0900

f:id:nnasaki:20170508142056p:plain

Azure Container Service ではオーケストレーションを選択する自由が有り、 Docker Swarm、Mesosphere DC/OS、 Kubernetes のいずれかを選べます。

3つも選べることは良いことなのですが、初めて使うと正直どれを選べば良いか迷います。

結論：Kubernetes を選ぶべき

結論から先に言うと Kubernetes を選ぶべきだと思います。今回はあまり技術的な部分（アーキテクチャ、機能性、安定性、性能）は触れずに、自分が普段行っている比較でまとめてみました。

理由1：Githubで比べる

OSSのプロダクトでどれを選ぶべきか迷った場合は、GithubのPulseを参考にすると良いです。Docker Swarm、Mesosphere DC/OS、 Kubernetes のそれぞれ1ヶ月分を見ていきます。

Docker Swarm

f:id:nnasaki:20170508130001p:plain

https://github.com/docker/swarm/pulse/monthly

Star数

4470 かなりある。

PR数

10 とかなり少ない

Issue数

Close より Open のほうが多く若干良くない兆候

Authors
3人と少ない

Mesosphere DC/OS

DC/OSはボリュームが少なかったので、marathonで比較した。

f:id:nnasaki:20170508140106p:plain

https://github.com/mesosphere/marathon/pulse/monthly

Star数

3233 かなりある。

PR数

12 とかなり少ない

Issue数

Close が多くて○

Authors
15人でまぁまぁ多い

Kubernetes

f:id:nnasaki:20170508125935p:plain

https://github.com/kubernetes/kubernetes/pulse/monthly

Star数

22956 他より一桁多い。

PR数

886 他より一桁多い。

Issue数

Close は多いが新規もかなりある。Issueも溜まっており、品質は問題があるかもしれないが、それだけ叩かれているということでもある。

Authors
172人他より一桁多い。
特定の人物に偏りが無く、OSSの存続性が高いといえる

OSSは止まってしまわないことが重要だと考えていますので、とにかく勢いがある Kubernetes に軍配が上がると思います。

Azure Container Service のエージェントを50にするとどうなるか？

Wed, 10 May 2017 06:00:00 +0900

Azure Container Service を使用して kubernetes のノードを50にしてみました。

f:id:nnasaki:20170508121911p:plain

VM数は53個

ノード50個にマスター3個で計53個になりました。圧巻です。リソースグループではネットワークインターフェンスなどがあるので計120個と表示されました。

f:id:nnasaki:20170508122051p:plain

CLIで仮想マシンをカウントするとキッチリ53個でした。

f:id:nnasaki:20170508122116p:plain

ストレージアカウントは４つ

ノード3つにマスター1つになりました。

f:id:nnasaki:20170508122324p:plain

このように各ストレージアカウントに分散してOSディスク用のblobが作られます。

f:id:nnasaki:20170508122443p:plain

ノード20個ごとに1ストレージアカウントが作られました。

TIPS:ストレージアカウントの制限について

ストレージアカウントごとにIOPSなどの制限があるので注意が必要です。

docs.microsoft.com

なお、管理ディスク(Managed Disk)を使用すればストレージアカウントの制限は無くなります。

ノード変更操作中のコンテナの動作について

50ノードとか課金が怖いので1時間もしないうちに5ノードに戻しましたチキンです。

ノード数の変更中もまったく問題ありません。ダッシュボードもデプロイ済みのアプリケーションも問題なく繋がりました。

まとめ

Azure Container Service のエージェント数の変更はまったく問題がありませんでしたが、ストレージアカウントの制限は気になるので管理ディスク(Managed Disk) の対応が早くされると良いなと思います。 ACS-Engine の Issue や kubenetes の issue を見ると、kubenetes の管理ディスク(Managed Disk) 対応はもう少し先になりそうです。

github.com

Azure Container Service を節約して使う

Tue, 09 May 2017 06:00:00 +0900

f:id:nnasaki:20170507230317p:plain

Azure Container Service で Kubernetes を使う記事を前回書きました。

blog.nnasaki.com

今回は Azure Container Service(ACS) を立ち上げっぱなしにしているとお金が結構かかるので、節約する方法をご紹介します。

EXTENDED BODY:

Azure Contaner Service の料金について

azure.microsoft.com

**ACS は、Virtual Machines (VM) をコンテナーサービスにクラスタリングする無料のサービスです。VM と、関連するストレージとネットワークリソースの使用した分だけをお支払いいただきます。

と、書いてあるとおりでコンテナーの管理サービスは無料ですが、中で動くVMなどのリソースの分お金がかかります。

具体的には今回サンプルで作ったリソースグループ内は全部で30リソースあり、次のようになっています。

f:id:nnasaki:20170507224134p:plain

f:id:nnasaki:20170507224159p:plain

f:id:nnasaki:20170507224220p:plain

特に仮想マシンはノード5つ分とマスター3つ分で合計8台あります。F2sで作成しましたので、8,727.12(円/月) * 8 (台) = 69,816.96(円/月)と中々痛い金額になってしまいます。

その他ストレージやパブリックIPアドレスなども出費はあるのですが、仮想マシンと比べれば微々たるものです。

仮想マシンを使わないときは割当を解除する

結論から言うと、Azure CLI などを使用してリソースグループ内の仮想マシンをすべて割当を解除**すれば良いです。コマンドはこちらです。k8s-southeastasiaをお使いのリソースグループ名に置換してください。

az vm deallocate --ids $(az vm list -g k8s-southeastasia --query "[].id" -o tsv) --no-wait

--ids オプションで複数のリソースIDを受け取って処理してくれます。

仮想マシンを使うときに開始する

開始もほぼ同様に次の通りです。同じようにk8s-southeastasiaをお使いのリソースグループ名に置換してください。

az vm start --ids $(az vm list -g k8s-southeastasia --query "[].id" -o tsv) --no-wait

Tips：仮想マシンをシャットダウンするだけでは課金は止まらない

実は stop というコマンドもあるんですが、こちらは仮想マシンをシャットダウンをするだけで割当を解除しません。

Azure Container Service 上の Kubernetes に Spring Bootをデプロイ

Sun, 07 May 2017 13:38:40 +0900

メイドさんが大好きなフリーランスのプログラマーさんが Azure Container Service について記事を書いていたので、自分も使ってみました。

blog.shibayan.jp

Azure Container Service は Marathon と DC/OS、Docker Swarm、または Kubernetes を使えます。

f:id:nnasaki:20170504215826p:plain

Azure クラウドでの Docker コンテナーのホスト | Microsoft Docs より

EXTENDED BODY:

しばやんが Kubernetes を使用していたので、違うのにしようかなと思いましたが、 Kubernetes を使用することにしました。

Azure Container Service を作成する

Orchestrator を Kubernetes で選びます。

f:id:nnasaki:20170504220005p:plain

SSH public key と Service Principal の設定がちょっと難しいですが、[i] の部分にマウスカーソルを合わせるとヘルプが出てくるので、それに従って進めていけばなんとかなります。

f:id:nnasaki:20170504220413p:plain

Agent は5つで、CPU4コアでメモリ8Gとバランスが良い F4S を選んでみました。

f:id:nnasaki:20170504221052p:plain

検証に成功したのでOKを押してしばらく待ちます。

f:id:nnasaki:20170504221241p:plain

コーヒーでも入れてゆっくりしようかと思ったらエラーで失敗してしまいました。

f:id:nnasaki:20170504221636p:plain

東日本は私のサブスクリプションではどうやらダメみたいなので、東南アジアの Standard_D2 で作り直します。

再デプロイをポチッと押して、変更します。

f:id:nnasaki:20170504221858p:plain

f:id:nnasaki:20170504222717p:plain

Marketplace から購入したわけじゃないけど、チェックを入れて購入を押します。

f:id:nnasaki:20170504222153p:plain

前は失敗すると、また一から作り直しだったんですが便利になりました。

東南アジアになってしまったのが不本意ですが、無事作成出来ました。