Kubernetesをぶち壊す10の奇妙な方法 (後編) - Qiita
はじめに これは、ZOZOテクノロジーズ #4 Advent Calendar 2019 13日目のエントリーです。 前回の前編記事に引き続き、Airbnbのエンジニアたちが経験したクラスターでのやらかしをあれこれご紹介します。 6. Where's my Custom Resource?（ワイのカスタムリソースはどこに？） AirbnbではKubernetesのCustom Resourceをよく使用しています。 特に、Kubernetesクラスターの外部にあるが、ストレージ、ダッシュボード、アラート、IAMロールなどのAWSリソースなどのサービスに関連付けられているリソースを追跡するために使っています。 こうしたCustom Resourceを使う上で大変なのが、「そのリソースがいつ利用可能になったか」や、「そのリソースに関する変更がいつ反映されたか」を検知することです。 最初のうちは
Kubernetesをぶち壊す10の奇妙な方法 (前編) - Qiita
はじめに これは、ZOZOテクノロジーズ #4 Advent Calendar 2019 12日目のエントリーです。 今回はKubeConに参加して面白かったセッションの1つである「10 weird ways to blow up your Kubernetes(Kubernetesをぶち壊す10の奇妙な方法)」をご紹介します。 この他にも、「Airbnbの事例に学ぶKubernetesとマイクロサービスのあり方 @ KubeCon Seattle 2018」という記事も執筆しているので、合わせてご覧ください。 また、このセッションのスピーカーであるMelanie Cebulaは、CloudNative Days Tokyo 2019のキーノートスピーカーとしても来日し、登壇しています。 後編書きました！ セッションの背景 セッションスピーカーであるMelanieとBruceは、Airbn
Docker Composeでコンテナのビルドが爆速に！？最新のDocker Composeを試してみよう - Qiita
Docker Composeでコンテナのビルドが爆速に！？最新のDocker Composeを試してみようDockerdocker-composeBuildKit はじめに この前至高のDockerイメージ生成を求めて -2019年版-を書いて多くの反響をいただきました。 この記事の中で「BuildKitを使うと軽量なコンテナのビルドが高速にできるようになる」と書いたのですが、実際のところ2019年現在において、Docker Composeの正式リリースではまだこちらの機能が使えません。 Docker for MacのEdgeチャンネルで2.1.5.0(40323)が降ってきて、BuildKitのComposeが使えるようになってました！！！！やったぜ！ これは、Docker ComposeではDockerのAPIと通信するのにPythonのライブラリであるdocker-pyを使っていて、
至高のDockerイメージ生成を求めて -2019年版- - Qiita
この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP
Kubernetesを始める前に必要そうな知識をまとめてみた - Qiita
概要 Kubernetesは、コンテナを基としたインフラのオーケストレーションツールです。 非常に多機能で、宣言的な記法でのインフラコード管理によって、柔軟かつ堅牢なインフラストラクチャを構築することができます。その一方で、(Kubernetesのみの知識に関わらず)非常に学習コストが高いという側面も持ち合わせています。 このエントリーでは、Kubernetesを知る上でその前提知識として必要そうなキーワードと、なぜ必要なのかという簡単な説明を書いていきます。 項目については、自分自身がハマったり困ったことがベースになっているため、もしかしたら足りない/多すぎるという意見もあるかもしれません。 ※筆者は偉そうに書きますが、筆者の理解が深いわけではないので悪しからず。 ツイッターにて募集をかけてみたところ予想を上回る反響をいただいたので、今回まとめるに至りました。 ↓元ネタツイート 【緩募】
IoT向けの軽量なKubernnetes(?) k3sとはなにか - Qiita
参考までに、Kubernetes単体の要件としては、API Serverを動かすのには1GB以上のRAMがあって、x86_64のCPUを使っているのが「望ましい」とドキュメントにはそれとなく書かれていたりします。ですが、実際にはもっと高スペックなマシンを利用するケースが多いはずです（無論、規模によります）。 それと比べ、k3sは非常に小さな環境でも動作します。どうしてなのでしょうか？ いくつか、特徴的な部分をピックアップしてみることにします。 Kubernetesの中で利用シーンの少ない機能を削っている Kubernetesには、後方互換性のために残しているレガシーな機能やAPIや、新たに追加されようとしているAlphaやBetaの機能が多数存在します。 k3sでは、軽量化のためにそれらの機能を削っています。 デフォルトのetcdをsqlite3にしている etcdは非常に高い信頼性を誇る
HTTP/3が出るらしいという話を雑に書く - Qiita
概要 インターネットに関する技術の標準化を司る、IETF(Internet Engineering Task Force)のWG(Working Group)において、HTTP-over-QUICが正式にHTTP/3という名前になることで合意が取れました。(ゆきさんからのご指摘内容を修正しました) しかし、そもそもこのQUICやHTTP/3って何なんでしょうか？ Webに関わる僕たちエンジニアにとってどういう関わり方をするのか、考えてみました。 この記事は怪文書ですので、雑と書いてあるところは私見として軽く流してください。 追記 詳解HTTP/3を翻訳しました！雑に理解したあとはこの本を読んでみるといいと思います。 QUIC・HTTP/3ってなに？ QUIC QUICは、Googleのエンジニアが提案した仕様が発端となって作られている、新しいトランスポート層のプロトコルです。 従来はgQU
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
