Kubernetesヘルスチェックの使い方
最近、Kubernetesのヘルスチェックについての質問をよく見ています。ここでヘルスチェックの種類の違いや、どう使うか説明してみます。 Liveness Probe Kubernetesのヘルスチェックは2種類があって、一つ目はlivenessProbeと、2つ目はreadinessProbeというやつです。livenessProbeの役目はアプリケーションが生きてるかどうかをチェックすること。普段、エラーが起きた時に、アプリがクラッシュで終了して、Kubernetesがそれを見て、再起動してくれるんですけど、livenessProbeはアプリが終了せずに動かなくなったり、デッドロックしたりする場合にもアプリを再起動して直すために存在する。アプリがちゃんと動いているだけをチェックしているので、単純にHTTPレスポンスを返せばいいはず。 簡単な例として、以下はGoアプリのlivenessP
Building Go Applications with Google Container Builder
Gopher image Creative Commons Attribution 3.0 Unported (ja) by tenntenn Recently I wrote on Twitter about how doing CI right requires you to properly separate your build and run steps for your container images. i.e. you have one Docker image to build your Go static binary, and one that's 3 lines long to copy it into a scratch image ;) — Ian Lewis (@IanMLewis) May 20, 2017 The reason for this issue
Kubernetesを拡張しよう
この記事は Kubernetes Advent Calendar 2016の第17日目の記事。 第１6目はyuanyingさんの 「Openstack で Kubernetes を使う」 でした。 KubernetesはDeployment, Secret, ConfigMap, Ingressなど、いろいろ機能があります。それぞれの機能はあることを自動化しているようなものです。 例えば、Deploymentはアプリケーションのデプロイ・更新を自動化するもの。Ingressはロードバランサーの作成・管理を自動化しているようなもの。その機能は便利ですが、ある程度Kubernetesに取り込んだら、自分で拡張したくなる場合がが多くなる。例えば、証明書の更新・管理の自動化だとか、etcdクラスターの管理の自動化だとか。 Kubernetesアーキテクチャ Kubernetesをどうやって拡張する
Appengine Matcher API
Matcher APIはあるオブジェクトが登録したクエリーにマッチするかをスケーラブルにチェックしてくれるサービスです。 クエリーが既に登録しているから、あるオブジェクトが一つ一つの登録したクエリーにマッチするかが他のクエリーに依存しないので、 Map-Reduce で簡単に平行で処理を分担してスケールできる。 何に使うか これが少し分かり辛いところかもしれないので、少し説明します。クエリーを未然に登録するので、 Prospective Search (プロスペクティブ検索、展望検索、予測検索?) と言います。 みんな使っている、普段の検索は、Retrospective Search (遡及検索) です。クエリーが決まってないので、データをインデクスを作って、後でユーザーがデータを クエリーする形になっています。 プロスペクティブ検索は、未然にクエリーを決めて、そのクエリーにマッチするデー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
