はじめに 最近コンテナやKubernetesの活動に参加を余儀なくされています。去年に少しかじったときに、まだまだ進化途中でこれを本番に入れるまでにはいろいろと周辺に必要だし、これはまだ来ないかな。そんな気持ちでいて一年ほど経ったのですが、最近風向きの変化を感じています。というのも、学びなおしてみるとここ一年で新しい概念がどっと登場していて基礎の骨組みに対して、様々なツールや商用パッケージ、サービスが登場しぐっとビジネスに近づいています。 せっかく勉強しなおしたので、Webにある有用な記事を集めてみました。 上から順番に読んでいくと、トレンドが理解できるのではないかと思います。 記事集 Kubernetesの基礎の基礎 PDFファイルですがこれよりわかりやすい資料はない。 Internet Week 2018 Kubernetesの基礎（著・日本IBM高良氏） Helm knowledge
Resource Requests Resource Requests とは podをデプロイする時に必要とするリソース(CPU/メモリ)を指定することができる仕組み。 ただしpodは指定したresource requests以上のリソースを使うことができる。(リソース使用量の制限はlimitを使う) またその指定したリソースがそのpod用に確保されるわけではない。 あくまでpodをデプロイ時にそのリソース量が空いているかをチェックするためのもの。 ポイントとしてはpodをデプロイするときに、nodeのリソース使用量は見ないで、resource requestsをみてデプロイが行われる。 なので、nodeのリソース(CPUやメモリ)の使用率が100%でも、resource requestsに空きがあればデプロイされる。空きがないnodeにはデプロイされない。 たとえばメモリ1Gのnodeが
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 注意 この記事は、実運用したことのない、Kubernetes初心者が調べた結果に基づき作成しています。 間違い・誤解などありましたら、コメントや編集リクエストでご連絡ください。 TL;DR / 結論から先に言うと コンテナをクラウドでそのまま動かそうとすると困る n台動かしたいコンテナが、今クラウド全体で何台動いているのかとか デプロイするときに、コンテナを立ち上げたり落としたりする順番・タイミングとか コンテナに割り当てるロードバランサ、ストレージなどの作成とか 他にもいろいろ Kubernetesはクラウド全体のコンテナ周りを一元管
Amazon ECSとKubernetesの統合サービスディスカバリー | Amazon Web Services
Amazon Web Services ブログ Amazon ECSとKubernetesの統合サービスディスカバリー 本日（訳注：2018年5月31日）から、Amazon Elastic Container Service（Amazon ECS）およびKubernetesによって管理されるサービスの統合サービスディスカバリーを活用することができます。私たちは最近、Amazon Route 53 Auto Naming（オートネーミング）APIを使用してサービス名のレジストリを作成および管理することにより、コンテナ化されたサービスの発見と相互接続を容易にするECSサービスディスカバリーを導入しました。サービス名は、一連のDNSレコードセットに自動的にマップされます。これにより、コード内でサービスを名前（backend.example.comなど）で参照可能となり、実行時にサービスのエンドポ
定額型パブリッククラウド という触れ込みで先日ローンチされたCloudGarage。 cloudgarage.jp そのフレーズのとおり、「1Core/ 1GB/ 50GB なクラウド VM インスタンスが3インスタンスで 1,480円/月 固定（転送量など込み）」という月額定額制のサービスメニューが用意されていて画期的。すでに趣味用途で AWS や GCP などにインスタンスをいくつか立ててる僕にはとても興味深いサービスなわけなんだけど、さらに魅力的なポイントとして、CloudGarage では「Dev Assist Program」なる、開発者向けインスタンス無償提供制度がある。 cloudgarage.jp この申請に通ると、上述の「1Core/ 1GB/ 50GB なクラウド VM インスタンス x3」が1年間無料で利用できる。そして先日、めでたく僕もこの制度の適用申請が通った。あ
Redirecting… Click here if you are not redirected.
kubectl create -f x.yamlでReplication Controllerを作成しコンテナが起動するまでに、各コンポーネントがどのように動作するかまとめてみました。Kubernetes 1.2時点での情報です。各コンポーネントの概要は、Kubernetes: 構成コンポーネント一覧をご覧ください。 シーケンス図 各コンポーネントはAPIサーバーのリソースを監視(watch)して非同期に動作するので、実際のアクセスの方向はコンポーネントからAPIサーバーになります。 kubectl createによるReplication Controller作成 kubectl create -f x.yamlでReplication Controllerを作成を実行すると、内部ではAPIサーバーのPOST /api/v1/namespaces/{namespace}/replicat
また、これらに加えてコンテナの実行やイメージの管理を行うためのDockerや、分散型設定共有サービス「etcd」も必要となる。そのほか、異なるマシン上で稼動しているコンテナ間で通信を行うためにLinuxのブリッジ接続機能や「Flannel」、「OpenVSwitch」といった仮想ネットワーク機構なども利用される。 これらのうち、apiserverやcontroller-manager、scheduler、etcdについてはクラスタの管理を行うマスターサーバーで実行されるコンポーネントとなる。また、proxyやkubelet、dockerはコンテナを稼動させる各ノード（minionとも呼ばれる）上で実行されている必要がある。 マスターサーバーとノードを分けた一般的な構成は、次の図2のようになる。なお、kubectlについてはマスターサーバー上でも、別のクライアント上でも実行が可能だ。 図2
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
