はじめに これは、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

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

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

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

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

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

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

はじめに これはコンテナランタイム好きのオタク記事です。DockerでrunC以外のランタイムを動かしてみようと思ってはいたもののずっとやれてなかったので、実際にやってみたら超簡単でした、という記事です。 ランタイムを変える意味について Dockerでは、コンテナを作成する機能をrunCという低レベルコンテナランタイムを用いて実現しています。 runCではLinuxカーネルの機能を呼び出すためにホストOSの特権を利用しますが、これはrunCの命令を実行する瞬間に悪意のあるコードを実行されると、ホストの特権を攻撃者に奪われてしまうリスクもあります。詳しくはrunCのこのへんとかを読んでみるとおもしろいかもしれません(?) ところで、runCというランタイムはOCIの標準仕様に基づいて作られています(厳密には、LXCを置き換えるために作られたrunCが持っている機能を標準化したものがOCIとい

TL; DR Docker/Kubernetes初心者の方と一緒に仕事をすることになったので、はじめの一歩として勉強会を開いたときに作成した以下の資料を公開しました。 speakerdeck.com 資料の目的 ZOZOテクノロジーズではたくさんのプロジェクトがあり、技術的にも古いものから新しいものまでいろいろなものが使われています。その多くは歴史的経緯や開発者たちのレベル感、今まで経験した技術などをベースに選定されることが多いです。 弊社 岡がCNDT2019にて発表した以下の資料や、ZOZOTOWNの作り直しの真っ赤な広告にもあるように、古い技術を使い続けてグロースを続けてきた結果、社内のプロジェクトのいくつかはスケーラビリティとして飽和に近い状態のものもあります。 ZOZOTOWNのCloud Native Journey from Toru Makabe www.slideshar