はじめに これは、Kubernetesアドベントカレンダー2の20日目の記事です。 これの話です。 aws.amazon.com ただし俺はもうEKS全然使ってないから意味ない件😢 なんの話？ 待ってたとは 4年前に、AWSでコンテナ使ってる人ならお馴染みのaws/containers-roadmapにこんなIssue(もとい、Feature Request)を作りました。 github.com また、これに関連するIssueとしてはその半年ほど前に作られていて github.com 自分としてはこのIssueを立てる前から技術選定の時点でずっと悩んでいたポイントだったので、かれこれ5年近く待っていたことになります。ようやくリリースされて本当によかった。まあ今はいらないんだけど、、、 どんな内容か これまでのEKSの課題点 EKSでクラスター管理者や運用者を指定する上で欠かせないのが、K

はじめに これは、Kubernetesアドベントカレンダー2の20日目の記事です、と思っていたら1の17日目が空いていたのでそっちに移します。 結論 htopはホストのリソースを取得できるカーネルの情報を見に行っているから！ 終 制作・著作 ━━━━━ ⓃⒽⓀ 終わりではない これだけだとアドベントカレンダーの記事としては内容があまりにも薄すぎるのでもうちょっと書きます。 この話を進める前に揃えておくべき前提知識の話。コンテナとVMの違いを説明する方法はいくつかありますが、決定的な違いとしては根本的にリソースの分離の仕方がちがうところにあります（細かいこというのもアレですが、ここではruncなどの標準的なコンテナ実装を用いた場合の話をしています）。 仮想マシンはホストマシンのリソースを（USBやPCIなどをパススルーする場合を除いて）基本的には全て隠蔽し、少ないリソースでデバイスのエミュレ

Docker一強の終焉にあたり、押さえるべきContainer事情 を読んで漠然とDockerが終わるって思った人、素直に手をあげてください。別にDockerは終わりません。なんかむしろWASMとかんばるぞって息巻いてて可愛いので頑張って欲しいと個人的には考えています。 その昔、Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog を書いたら炎上しました。最初の記事の書き方が良くなかったという反省はあるにせよ、世間一般で「Dockerは開発環境で使うやつ」という認識があまりにも広がりすぎているというのが良くわかる勉強の機会になりました。 逆を言うと、みなさんがこれらの記事を読む時には、Dockerという言葉に含まれる意味に注意して読んでいただきたいと思っています。Dockerには大きく分けて以下の意味が含まれると僕は考えています。 Docke

はじめに これは転職エントリーです。この2年出社はしていませんが、一通り仕事を終えたので投稿ってことで自分のブログに自分語りをします。「お前誰」っていう人はツイッターや過去のブログ記事でも読んでからお読みください。 2020年3月に公開したこちらのエントリーでは、ZOZOを退職した話を書きました。その後これまで2年ちょっとの間はHPE(日本ヒューレット・パッカード合同会社)にてクラウドアーキテクトとして勤務していました。人によってはHPEよりもZOZOのイメージが強いかもしれませんが、実はHPEの方が若干在籍期間が長いです。 blog.inductor.me 在職中は国内外・大小問わずいろいろな案件に関わらせていただいて、事例紹介のページにもおもしろスーツぽっちゃり写真が出ています。気になる方は探してみてください。 転職します、という話 ※転職先については隠す必要は実はないのですが、最近ち

TL; DR YJITをDocker/Kubernetesでで有効にするには RUBY_YJIT_ENABLE=1 or RUBYOPT=--yjit YJITはデフォルトで256MBのメモリ領域を確保するため、全体のメモリ消費量が上がる Docker/Kubernetesでメモリ量を制御したい場合、RUBYOPT=--yjit-exec-mem-size=128のようにメモリ確保量を変更すればよい Ruby 3.1から使えるYJIT Ruby on Railsで動くアプリケーションでRubyのMJITが効果的でないことは色んなところで書かれていて、Ruby 3.1から実験的に導入されたShopify製のYJITでは対照的にRailsでのパフォーマンス改善が見込めるという期待があります。 ただしこのYJIT、動かすときには(JITなのでそりゃそうですが)デフォルトで256MiBのメモリを確

はじめに Launchableの共同創業者の1人で、Jenkinsの父としても知られる川口耕介さんとMSでアドボケイトをされている寺田佳央さんのご紹介で、西海岸サンタクララにヘッドクオーターを置くShipa.ioというスタートアップのカジュアル面談を受けてみました。日本でプロダクト開発をするエンジニアを募集したいとのことで、紹介の意味も込めて創業者の1人であるVivek Pandeyとカジュアル面談をしたときの内容や感想を書いてみます。 はじめに Shipa.ioについて Shipa.ioは日本でのエンジニア部隊を立ち上げたい どんな人を探している？ Shipaのチームメンバーは世界中にいる 英語話せないときついんじゃないの さいごに Shipa.ioについて Shipaはエンジニアの開発からデプロイまでを支援するプロダクトで、SREがポリシーを定めるところから開発者がデプロイをするまでを

はじめに この記事ではAWSの公式ブログ「Amazon EKS adds native support for Bottlerocket in Managed Node Groups」で取り上げられている内容を、eksctlを使わずCloudFormationでimmutableに実現するための方法を解説します。 aws.amazon.com Bottlerocketとは Bottlerocketは、AWSが開発しているコンテナ実行専用OSです。Fedora/RHELのCoreOSやVMwareのPhoton OS、Rancher OSなどと似ていて、コンテナを実行するためのランタイム以外余計なパッケージが入らない軽量なOSとなっています。 aws.amazon.com Bottlerocketの開発状況についてはBottlerocket Roadmap · GitHubを合わせてみると良

はじめに この記事は筆者がKubeCon EU 2021にて発表した「Resource Requests and Limits Under the Hood: The Journey of a Pod Spec」の内容を中心とし、ブログ向けにまとめなおしたものです。 www.youtube.com 日本語でこのリソース要求/制限について内部の仕組みまで踏まえて詳細に書かれた記事はあまりないので、誰かの助けになれば幸いです。 はじめに Kubernetesにおけるリソースの要求と制限 スケジューラーによるスコアリング ノードでのPod作成処理 Requests全体の流れ Limits全体の流れ CRI内部の処理 OCI内部の処理 まとめ Kubernetesにおけるリソースの要求と制限 Kubernetes上でアプリケーションを実行する際、ワークロードの特性に応じて以下のような形で必要なリソ

はじめに この記事は、以下のlwn.netの記事を抄訳したものです。 lwn.net CPU Namespaceのご紹介 これはCPU namespaceのインターフェスとそのメカニズムを証明するための初期プロトタイプです。 現状におけるCPUリソースの制限方法 Linuxカーネルでは、タスクのCPUリソースを制御するために2つの方法を提供します。 cgroup cpuset: 該当のグループにアタッチされた単一または複数のタスクの集合に対し、CPUリソースを制限するためのメカニズムです。 syscall sched_setaffinity: CPUの集合に対して特定のタスクをピニングするためのシステムコールです（訳注: NUMA利用時の条件下などにおいてよく利用される手法）。 また、カーネルはシステムにおいて利用可能なCPUリソースを閲覧可能にするために3つの方法を提供します。 sys/

はじめに こんにちは。inductorです。 Kubernetesについて学ぶための1つの方法として、CKA/CKAD/CKSといった公式の資格の存在があります。資格保有が必ずしも専門性を示すわけではありませんが、特にベンダーの技術者や普段業務でKubernetesを使わないという方の場合、資格試験の勉強は効率の良い学習リソースの1つと言えるでしょう。 ところで、技術の資格試験を作ることについて考えたことはあるでしょうか。僕はこれまで深く考えたことはありませんでした。そもそも、誰がどういうプロセスで資格試験を企画し、設計しているのかすら知りませんでした。CKSのときはクローズドベータテスターの募集があってそれを受けたりはしたんですがそれはそれでただの受験者なので特に何も考えてはいなかったですね。 CKADの試験改定の募集 今年の春に、CNCF Ambassadorの集まるSlackチャンネ

はじめに HPE(Hewlett Packard Enterprise)にてアーキテクトをやっているinductorです。久しぶりに社内勉強会というやつに参加して発表することになったので、発表資料を共有します。 なお、発表資料自体10分で話すためにぎゅっと圧縮してしまっているので、このブログでは、LTで話しきれなかったクラウド実装についてもう少しだけ細くを書いておこうと思います。 speakerdeck.com コンテナネイティブロードバランシングについて Kubernetesではいわゆる外の世界とKubernetes内部の世界で大きくネットワークの仕組みが分かれています。これをつなぎこむための仕組みとして、3つのネットワークとそれぞれをつなぎこむコンポーネントが存在します。 Node network(VMや物理マシンがNICでつながるデータセンター/VPCのネットワーク) Service

はじめに GitOpsという言葉が生まれたのが自分の知る限り2017年頃なのですが、世の中にあるCI/CDの仕組みはまだほとんどがCIOpsもしくは手動のオペレーションによって成り立っていると思っていて、かつては自分もそうだったのですが「Gitで管理されていればGitOpsなんでしょ？」という勘違いを払拭したくてこのエントリーを書いています。 GitOpsとCIOpsは全然違う まず前提としてGitOpsの明確な定義を知らないという場合、あなたの思う「Gitを契機とした自動デプロイの仕組み」は基本的にはCIOpsです。GitOpsとCIOpsは思ったよりも大きな違いがあって、そもそもGitOpsの必要性が分かっていない場合、自動化によって成立しているデプロイはCIOpsが基本です。 CIOpsとGitOpsの一番の違いは、Push型かPull型かである CIOpsの場合、例えばGitHub

はじめに EKS Anywhere(EKS-A)とは じゃあ、何をするCLIなの？ EKS Distro(EKS-D)とは 刺さるユースケースは・・・？ EKS Connectorの話 EKS-AとEKS Connectorの組み合わせ 1. クラスター管理をeksctlに一本化できる 2. クラスターAPIによるメリットが享受できる 3. AWSの管理画面からワークロードの様子などが確認できる 他にもいろいろ さいごに はじめに この記事はEKS Anywhere(EKS-A)がGAになった最初の時点での情報です。あくまで参考程度にご覧いただけると幸いです。 先にみなさんに誤解がないように言っておくと、EKS-Aは以下のどの製品（サービス）とも異なる性質があります。そのため比較検討の対象ではないことを認識しておくと良いです。 Google Anthos Tanzu Kubernetes

はじめに Kubernetesは直近3マイナーバージョンをUpstreamのサポート対象にしており、特に1.19以降では各バージョンごとに1年のパッチサポートがあります。2021年7月現在の最新版は1.21なので、1.19以降の3マイナーバージョンがサポート対象になっています。詳細については公式ドキュメントにも記述があります。 なお、GKE、EKS、AKSなどのKubernetesディストリビューションに関するサポートポリシーはUpstreamとは違い各ベンダーが責任を追っているため、各社のドキュメントをご覧いただければと思います。 KubernetesのAPI deprecationについて Kubernetesではマイナーバージョンごとに新しい機能が追加されたり、古い機能や利用の少ない機能を非推奨化または廃止するためのポリシー、Deprecation Policyが決められています。

はじめに 以下のエントリーでも書いたとおり、今年のGW期間中に行われたKubeConにて2件のセッションを採択いただき、スピーカーとして登壇していました。 blog.inductor.me 前回エントリーでは応募のきっかけを大まかにまとめましたが、そこからどのようにしてセッションを考えたかや、CfP(Call for Proposal)を提出するにあたってどのように進め、登壇内容を作り上げるにあたって行った調査などにもある程度踏み込んで書き記します。なお、セッションとしては2件でしたが、パネルのほうは録画のみで資料が残っていないため、Resource Requests/Limitsについて発表した以下セッションのみ取り上げていきます。 はじめに Resource Requests and Limits Under the Hood: The Journey of a Pod Spec -

はじめに このエントリーは、Google Cloudのエンジニアである@ahmetb氏のブログ記事を日本語訳したものです。 以下のツイートを見つけて、良さそうだったので翻訳の許可をいただきました。 Mastering KUBECONFIG article has been the top read page on my blog over the past year. 🤷🏼‍♂️ Not sure what to make of this. https://t.co/t4pWwOpgQW— Ahmet Alp Balkan (@ahmetb) March 11, 2021 KUBECONFIGのすべて kubectlが動作するその裏側には、kubeconfigというファイルの存在があります。このファイルは一般的には$HOME/.kube/configに存在しています。私がkubectx

はじめに やめろ、ではなく、やめたほうがいい。です。自分のユースケースに合ってるか今一度確認することを推奨します。基本的にはAlpineは避けたほうが良い、というのが2021年時点での私の認識です。 なんで？ libcに一般的な互換性が不足しているからです。Ruby、Python、Node.jsなどでNativeモジュールをバンドルしているアプリケーションの場合、パフォーマンスの劣化や互換性の問題にぶち当たる場合があります。 superuser.com あとは他のベースイメージの軽量化もそれなりに進んできていて、Alpineが定番軽量イメージと言う認識は2018年頃には消えつつあったかなという認識でいます。 どうすりゃええねん ※Debian Slimがあるやんってツッコミ結構もらったんですが、Slimは当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい

はじめに GoogleのマネージドKubernetesディストロであるGKEの新機能（厳密には新しい種類のクラスターといったほうがユーザーにとっては正しい説明になると思いますが）、GKE Autopilotが先週大きく話題になりました。 ノードがGoogle Cloudによるマネージド Podごとの課金体系 ノードへのSSHが使えない といった特徴が大きく取り上げられており、ぱっと見AWSのEKS Fargateと非常に似ているように見えます。が、(少なくとも、user facingな部分においては)技術的には全くやっていることが違うと思います。なぜならFargateはEC2とは全く異なるVM技術がベースになっているのに対して、Autopilotは通常のGCEを応用した機能として提供されているからです。 ※まあ、GCEは実はコンテナで動いてるみたいなちょっとした裏話もあったりするんで、本当

はじめに 今朝に書いたブログが思ったより反響が大きくて、「Dockerが死んだ」という勘違いをされている方も多かったので追加でエントリーを書きました。 blog.inductor.me 決してそんなことはないので、対応が必要なケースを見ていこうと思います。 はじめに 対応が必要ではないケース Kubernetesを使わない人たち 本番はKubernetesでも、開発にDocker Composeを使っているデベロッパーの開発環境 対応が必要なケース 開発環境でも手元でKubernetesを利用する人たち NVIDIA DockerをKubernetesで使っている人たち Kubernetesワークロードの中で「Docker in Docker」や「Docker APIに依存した処理」を動かしている場合 Dockerの機能を使ってこれまでやっていたことについて 対応が必要ではないケース Ku

追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね！！！」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合