KubernetesのSchedulerを評価するためのシミュレーター「k8s-cluster-simulator」公開 - Preferred Networks Research & Development
概要 2018年夏のインターンおよびPEとして勤務した薮内さんとそのメンターである谷脇、大村で開発したKubernetesクラスターのシミュレーターであるk8s-cluster-simulatorのアルファ版をオープンソースとして公開しました。このシミュレーターはKubernetesクラスタに投入されるPodのワークロードを時間とともにシミュレートできるため、Kubernetesのスケジューラーを本番環境に投入する前に評価することができます。 開発の動機 PFNでは巨大なオンプレのGPUクラスタを持っており、その上でKubernetesを使って様々な実行時間の機械学習ジョブを研究者が実行しています。我々クラスターサービスチームのミッションの一つとして、GPUの利用率を向上させ費用対効果をあげることが挙げられます。一方で、研究者間で使えるリソースの平等さも考慮しなければなりません。これを実現
Kubernetesはクラスタで障害があったとき、どういう動きをするのか - あさのひとりごと
Kubernetesは、コンテナアプリケーションをデプロイするためのオーケストレーションツールです。Kuberenetesは分散環境におけるスケーラブルなコンテナ実行環境をつくるための、さまざまな機能が提供されています。 もともとはGoogleが開発したBorgをもとにOSS化したものですが、今日ではマイクロソフトやRedHatも積極的に開発に加わり、非常に早いスピートで機能拡張していて、追いかけるのも大変です。 Kubernetesの大きな特徴は宣言的設定にあります。 この宣言的設定とは、イミュータブルなインフラを作るための基本的な考え方で、「システムのあるべき姿」を設定ファイルにて宣言する！という考え方です。Kubernetesは設定ファイルに書いたとおりのインフラを維持するように設計されています。 Kubernetesはコンテナを「Pod」という単位で管理します。このPodをKube
Kubernetesを拡張しよう
この記事は Kubernetes Advent Calendar 2016の第17日目の記事。 第１6目はyuanyingさんの 「Openstack で Kubernetes を使う」 でした。 KubernetesはDeployment, Secret, ConfigMap, Ingressなど、いろいろ機能があります。それぞれの機能はあることを自動化しているようなものです。 例えば、Deploymentはアプリケーションのデプロイ・更新を自動化するもの。Ingressはロードバランサーの作成・管理を自動化しているようなもの。その機能は便利ですが、ある程度Kubernetesに取り込んだら、自分で拡張したくなる場合がが多くなる。例えば、証明書の更新・管理の自動化だとか、etcdクラスターの管理の自動化だとか。 Kubernetesアーキテクチャ Kubernetesをどうやって拡張する
Consul クラスタ上で動作する S3 非依存の pull 型デプロイツール "fireap" を作った - weblog of key_amb
github.com fireap = fire + reap です。 Consul Event を発火(fire)して、受信側でそれを収穫(reap)する、という意で。 読み方は「ファイリープ」で良いかと思ってます。 どんなツール？ GitHub に上げた README.md より、かいつまんで日本語に変換しつつ説明します。 ノード数 N に対して O(log N) で動作するデプロイツールです。 が、実際にはデプロイに限らず任意のコマンドを実行できるので、README の中ではデプロイツールとは書いておらず、「高速タスクランナー」としています。 fujiwara/stretcher や sorah/mamiya は O(1) なので、それらが使える環境(S3 的な I/O やトラフィックの上限が非常に高いストレージがある)でデプロイを速くしたいという場合は、それらを使えばよろしいかと。
consulとconsul-templateでAPサーバの自動切り替え - Qiita
概要 Consulとは: サービス検出、障害検知とか。 Consul-templateとは: 障害を検知した時、用意されたテンプレートに ようするに、障害対応など色々と自動化してくれます。それを両方触ってみたという内容です。 やったこと APサーバがconsulクラスタに追加されたら、nginxのconfファイルに動的追加してreload APサーバがconsulクラスタからleave、もしくはサービスダウンしてたら、nginxのconfファイルから削除してreload APサーバが全部shutdownされたら、nginxのconfファイルにsorryサーバだけに記述してreload 構成 ※ 各サーバの構築手順はこちら：consulとconsul-templateでAPサーバの自動切り替え ~環境構築編~ 役割 IP 補足
Consulサーバクラスタ構成手順の歴史 #consul - クリエーションライン株式会社
Consulとは Consul とは、米 HashiCorp 社が開発する、サービスの検出と設定を行うための仕組みです。クライアント・サーバ型の構成で動作し、キーバリューストア(KVS) に保持したデータを DNS や HTTP インターフェイスで取得できます。クライアントとサーバはそれぞれがクラスタを構成し、インターネット越しに別々のデータセンターをまたいで接続することもできます。 詳しくは公式サイトのイントロダクションやドキュメントを参照してください。 Consul サーバクラスタ Consul サーバはクラスタとして動作します。1台でも動作しますが、冗長性・耐障害性を高めるために 3台あるいは 5台での運用が推奨されています(参考: Deployment Table)。 ここでは 3台の Consul サーバによるクラスタを構築することとします。事前に 3台のマシンそれぞれに Con
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
