Kubernetes

問題 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 が 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分というところです。 十分高速かなと思います。 検証方法 下記サイトを参照して行いました。詳細を書こうと思ったんですが力尽きました。。。 また別の機会に書きたいと思います。 ...

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

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 を使用して 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 github.com

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 について記事を書いていたので、自分も使ってみました。 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 前は失敗すると、また一から作り直しだったんですが便利になりました。 東南アジアになってしまったのが不本意ですが、無事作成出来ました。 ...