はてなブックマーク

はじめに これは、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などをパススルーする場合を除いて）基本的には全て隠蔽し、少ないリソースでデバイスのエミュレ

インフラエンジニアの肩書きをSREに変えるタイプの組織変更は近いところから遠いところまでいろんなところで見かけてるんだけど、改めてそれって名前変えただけじゃないよね？って問いかけは個人が組織に、組織が個人にそれぞれ相互でした方がいいと思う。 インフラエンジニアって言葉もまあ定義が死ぬほど広くてどこからどこまで指すのってのは組織によって違うね大変だねって話ではあるんだけど、SRE(Site Reliability Engineering)やPE(Platform Engineering)はインフラと必ずしも対応関係にあるわけではないんだよな。 Platformってのは言ってしまえば会社のエンジニア組織の中で自分達に最適化された基盤を作る人たちの集合体とそのプロダクトそのものを指していて、Platform Engineering組織の中には当然フロントエンドエンジニアやデザイナー、プロダクトオ

こちらのPublickeyの記事だけ見て中身がよくわかってなさそうな人がちらほらいたので、KubeVirtを使うことの意味についてちょっと書いてみようと思う。 www.publickey1.jp ただのちっちゃなVM基盤が欲しい場合は、ほぼ不要なもの 勉強目的などを除き、仮想マシンの数が10に到底届かないような仕組みでKubeVirtを動かす場合、かなり勿体無いので採用する意味はあまりないと思う。Kubernetesを動かすことによるオーバーヘッドがかなり大きいし、正直物理的な冗長性が十分無視できるくらいの規模と言わざるを得ないので仮想化基盤としてKubeVirtを採用するメリットは薄い。EC2とかESXiとかProxmoxとか既存の仕組みを使えばいいんじゃない？と思う。 採用に値するであろうメリット1: IaaSを作りたい場合 KubeVirtの本質は、「KubernetesのAPIを使

sad記事の勉強と実践のボリュームがすごい https://blog.ojisan.io/server-architecture-2023/ を読んで、その前身とも言える https://blog.yuuk.io/entry/2015-webserver-architecture を含めてこれらのような記事を書く知識や経験が僕には無いから素直にすごいと思った。ただ、その一方でこの内容を普通に理解できる「Webエンジニア」はどのくらいいるんだろう？というのも同時に気になった。 ゆううきさんの記事は「序論」とあるがWebエンジニアとしてキャリアを積む人間が「序論」として読むには文量や背景知識が重すぎると正直思うし、システム・計算機工学を勉強した人間が背景に感じ取れる。事実、sadさん(おじさん)も昔は内容が分からなかったと本人記事内で言及しているため、僕の気のせいではないと思う。じゃあsad版

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

社内のことは多くは書けないので、部署の雰囲気やチームでのやりとりについて、書ける範囲で書いてみる。お約束っぽくなってしまうが、これはあくまで個人としての経験・意見を書いたもので、会社の意見や思想を代表するようなものではないことに留意いただきたい。また、構造化した文章を書くつもりはないのでMarkdownは使わずにだらだら書いていく。 多くの人が中身や実態について知りたがっている一方で、ちょっとボロを出すとすぐブコメとかでネガキャンしてくる勢力がいて面倒なので書くか大いに迷ったのだが、純粋にその中身にポジティブな方向で興味がある人や、あるいは入社のハードルを少しでも下げたいといった気持ちで実験的に記事を書く。よって、書かないことは書かないし、それ以上追記をするつもりも特にない。ソーシャルのDMでも質問は基本的に受け付けていないので、どうしても知りたい人はカンファレンスなどで自分を捕まえて話し

これは何 以下記事のアンサーブログです。 qiita.com 以下のことはコメントに書いたんですが、書ききれなかった部分もあったり整理したほうがいいなと思い記事に起こしています。 現代のアプリケーションではC10K問題よりも先にDBやアプリケーションのボトルネックが先に来るため、C10K問題に遭遇するよりも先にやることがある ミドルウェアとしての成り立ちから設定ファイルの書き方に至るまで、それぞれのソフトウェアで思想が根本的に異なるので、単なるパフォーマンス比較をしてもあまり意味がない NginxとApacheの違いをC10K問題を中心に語るのは時代が違う この記事に限らず、多くの「Nginx vs Apache」系記事では「ApacheはC10K問題を抱えている」という論理をベースにそれぞれの違いを表現しています。 が、これは2022年においては(実際にはもっと前からですが)既に事実では

はじめに これは転職エントリーです。この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のメモリを確

はじめに これは、監視ひよっこの inductor が Prometheus Operator に入門したときの記録です。意外と情報が古いものが多く、2022年現在だと何をどう入れるべきなのかがよくわからなくて困ったので誰かの助けになれば幸いです。 Prometheus Operator とは Prometheus Operator は名前の通り Kubernetes のオペレーター実装の1つで、主要な監視ツールの1つである Prometheus 及びその関連コンポーネントを Kubernetes リソースとして管理できるようにしたものです。主に以下のようなリソースを管理することができます。 リソース名 役割 Prometheus Prometheus のデプロイ管理 Alertmanager Alertmanager のデプロイ管理 ThanosRuler Thanos Ruler をリ

Kubernetes v1.22 から kubeadm.k8s.io/v1beta3 が利用可能になっていたのを、年末に実家のクラスターをいじいじしてたときに気づきました。kubelet.config.k8s.io/v1beta1 と kubeproxy.config.k8s.io/v1alpha1 は据え置きですが、InitConfiguration、ClusterConfiguration、JoinConfiguration がそれぞれv1beta3 で使えるようになっています。 kubernetes.io kubeadm でクラスターをセットアップする場合、kubeadm init --オプション という形で設定値の引数を渡すこともできるのですが、できるだけ --config の中で渡したほうが引数の管理がしやすく、deprecated になったときに対応策を考えやすくなります。 v

はじめに これはKubernetes Advent Calendar 2021 4日目の記事です。 今回はAWSが先週GAを発表した「Karpenter」について、実際に触ってみた様子とOSSとしての思想やデザインについて書いてみます。 Karpenterとは Karpenterの公式ページでは「Just-in-time Nodes for Any Kubernetes Cluster」と説明があります。つまり、KubernetesノードをPodが必要とした瞬間に用意するようなプロダクトを目指していることになります。まずは前提を揃えるためにKubernetesのオートスケーリングについて簡単に説明します。 Kubernetesのオートスケーリング Kubernetesにおけるオートスケーリングには大きく分けてコンテナ(Pod)レベルのスケーリングとノードレベルのスケーリングがあります。「H

はじめに この記事は以下CNCF公式のアナウンスを日本語で抄訳したものです。全文及び詳しい内容については該当記事を合わせて御覧ください。 www.cncf.io KCNAとは Kubernetes and Cloud Native Associateの略称で、これまでKubernetesの資格試験として存在していたCKA、CKAD、CKSよりも入門者向けの内容で構成される資格試験です。 入門といいつつそれなりに幅広いトピックについて扱うため、エンジニアではないがこれらの技術を扱う企業・ベンダーのセールスやマーケティングの方向けにも提供されているようです。CNCFのCTOであるChris Aniszczkは以下のように発言しています。 As cloud native has grown beyond just Kubernetes, the need to understand the la

はじめに この記事では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/

はじめに Amazon EKSを初期導入すると、最小限の構成でクラスターがセットアップされそのままの構成で本番運用をするのはとてもじゃないが厳しいみたいな状態になっています。 これには運用者が柔軟にミドルウェアを選定できるというメリットもありますが、そもそもどんな選択肢があるんだっけみたいなところまではちゃんと整理できていないと思うので、ここでは僕が考える入れておくべきアドオンについて今後のために整理しておきます。 github.com/aws/eks-charts を眺める とりあえず脳死でこのサイトに行き、自分に必要そうなものを眺めることにします。Helmを使ってインストールするかどうかはさておき、それぞれのツールの必要性について検討しようという話です。 github.com App Mesh関連 App Meshを使ったサービスメッシュをやっていきたいのであればこの辺のコンポーネント

はじめに 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が決められています。

はじめに はじめに Kubernetesでの対応 imagePullSecretsを使いたくない... kubeletが実はDocker credentialを読み取れる実装になっていた Docker Hubはコンテナレジストリとしては世界で最も広く使われるサービスですが、去年の秋頃からイメージをPullする際に同一IPからの短期的なアクセスに制限がかかるようになりました。 docs.docker.com なお、Docker Pullの実際の制限数を知るには以下のリクエストを送ることでレスポンスヘッダーに記載されます。 $ TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token) % To

はじめに 以下のエントリーでも書いたとおり、今年の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 -

はじめに 先日開催されたKernel/VM探検隊online part2ではWASMが大きなトピックの1つでした。 connpass.com 僕はWASMに関して一切話しませんでしたが、以前からKubernetesにおけるWASMの活用の話や、CDNなどのエッジクラウド環境におけるWASMの活用については情報を集めていました。 TechFeed Summit#3 - コンテナ技術を語り尽くす！では、エッジにおけるKubernetes利用のこれからについてもLTでお話させていただき、その中で一つの利用例としてKrustletとWASMの話も言及しています。 speakerdeck.com 下記スライドではKrustletのアーキテクチャをKubeletと比較していますが、見ての通り、これまで「コンテナ」が動いたPodを置き換える形として「WASM」が動いていることがわかります。 WASMはコ

はじめに このエントリーは、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は当たり前過ぎてもう紹介しなくていいかなっていう甘えで省略していました。よろしくおねがい