23. 25 Deliveryrate BDP BDP+BufSize RTT Optimal: max BW and min RTT (Kleinrock) amount in flight Optimal operating point 23 Deliveryrate BDP BDP+BufSize RTT Loss based CC (CUBIC / Reno) amount in flight Loss based congestion control in deep buffers BDP = (max BW) * (min RTT) 26 Deliveryrate BDP BDP+BufSize RTT amount in flight Est min RTT = windowed min of RTT samples Est max BW = windowed max of
#課題 突然キャンペーンとかの高トラフィックが来る！とか言われると色々困ることはあるものの、今のご時世クラウドだからスペック上げときゃなんとかなるでしょ。ってとりあえずCPUとかメモリあげて見たものの、キャンペーンが始まったら意外と早くブラウザからつながらない！！とか言われたりする。 CPUもメモリもそんなに負荷は特に高くもない。調べてみたらTIME_WAITが大量にあった。 #とりあえず何とかしたい ####TIME_WAIT数をコマンドで確認 $ netstat -anp|grep TIME_WAIT __(snip)__ tcp 0 0 192.168.1.1:80 192.97.67.192:56305 TIME_WAIT - tcp 0 0 192.168.1.1:80 192.63.64.145:65274 TIME_WAIT - tcp 0 0 192.168.1.1:80
はじめに Kubernetes 上のアプリケーションに対して、curl や tcpdump など使い慣れたツールを使ってデバッグを行いたいと思う場合があるかと思います。kubectl exec を利用するとコンテナ内のコマンドを実行することができ、従来 ssh で行っていたデバッグに近いことが可能になります。一方、コンテナには必要最低限のものしか含めないことがベストプラクティスとなっているため、使いたいコマンドが含まれていないこともあるでしょう。 本記事では、kubectl exec を主としたデバッグの方法と、コンテナに使いたいコマンドが含まれていない場合や kubectl exec が利用できない場合の対応方法などについて説明します。確認は Kubernetes v1.8 で行い、コンテナランタイムは Docker を前提としています。 kubectl exec を使ったデバッグ ku
コンテナ関連 クラウド Kubernetes ネットワーキング 2017/10/02 技術本部 クラウド基盤エキスパート 工学博士 岩本 俊弘 Kubernetes でのネットワーク実装についていくつかの例を挙げて解説していきます。 Kubernetes でのネットワークと言った場合、以下の2つの解釈ができます。 Kubernetes 上のアプリケーション(Pod)側から見たネットワーク 上記の(仮想)ネットワークを実現するための Kubernetes 側の実装 (下回り) 本書では 1. を簡単に説明した後、主に 2. について解説していきます。なお、kubernetes のバージョンは 1.7 を用いています。 Kubernetes は Pod 毎に IPアドレスを割り当てます。同一 Kubernetes クラスタ内の Pod はその IPアドレスを使って相互に通信できます。 この図の
ネットワークエンジニアから「Linux Bridgeがわからん」と言われて説明用に書いたLinuxホスト内部ネットワークの概念説明と作り方です。 実用的なものが必要ならば以下のリンクがわかりやすいかと思います。 http://kurochan-note.hatenablog.jp/entry/2015/10/11/110649 http://ameblo.jp/principia-ca/entry-12103919307.html なお、リソースさえあればコンテナよりもVMで構築したほうが圧倒的に楽です:-) 環境 ・OS CentOS7 ・ルーティングプロトコル OSPF(on quagga) #前提知識 Linux内に以下のものを複数作成することができる ・インターフェース ・ブリッジ ・ルーティングテーブル、プロトコルスタック #シナリオ こういうネットワーク作ってと言われました。
こんにちは。SPEEDA開発チームの鈴木です。 これまでマルチホストでのContainer間通信について、 Dockerのネットワークの基礎(前々回) マルチホストでのContainer間通信を実現する手段の一つとしてのOverlayNetwork(前回) といった話をしてきましたが、3回目となる今回はこれまでの内容を踏まえた上でKubernetesのネットワークについてお話します。内容としては大きく次の2つになります。 どうやってマルチホストでのContainer間通信を実現しているか Service名でPodと通信できるようするための仕組み では早速1つ目の話をはじめましょう。Kubernetesを利用する場合、基本的には複数のノード上にKubernetesクラスタを構築することになります。 （minikubeを使って単一ノードからなるKubernetesクラスタを構築するような例外は
Google によるフルマネージドサービスである GKE では Kubernetes のマスタやノードのことは理解しなくとも Kubernetes の API を使って実現したいことに集中できる。 しかし、本番運用をはじめてから「なぜ動いているのかもなぜ動かないのかも分からない」というような状態ではいざという時に困る。 特に Service がどのようにクラスタの外から Pod へのアクセスを提供しているのかはブラックボックスになっていたため、今回は GKE での Service の L3(〜L4) の挙動について Kubernetes の内外を調査した。 (後で図や参照情報へのリンクを追加予定) 図解が出てきたので追加しなかった。 追記(2018年10月5日) Kubernetes Engine の Network Overview が良いのでこちらも読むと良いでしょう。この記事を書いた
Why Service is the worst API in Kubernetes, and what we can do about it
netnsでネットワークの勉強 tl;dr netnsというlinuxのネットワーク機能を紹介する。 netnsをコマンドレベルで触ってみて、基本的なネットワークの勉強をする。 netnsとは linuxにNetwork Namespaces(netns)という仕組みがある。 Linux Namespacesと呼ばれるリソースの仮想化のための機能の一部で、名前の通りネットワークの機能を提供する。 docker等でも用いられている技術で、コンテナ毎に異なるネットワーク設定が行える部分で用いられている。 具体的にはプロセス毎に異なるIPアドレスを使って通信するといったことができるようになる。 docker使えば? dockerや各種コンテナ技術がnetnsをうまく隠してくれているのに、わざわざnetnsを直接触る必要がないと思った方。 その通りで、ここでは勉強用に使うことを想定している。 (も
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
