<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Networking - Tag - Lorenzo's Blog</title><link>https://www.k8s.it/tags/networking/</link><description>Networking - Tag - Lorenzo's Blog</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Mon, 22 Feb 2021 00:00:00 +0000</lastBuildDate><atom:link href="https://www.k8s.it/tags/networking/" rel="self" type="application/rss+xml"/><item><title>Kubernetes nstats</title><link>https://www.k8s.it/posts/kubernetes-nstats/</link><pubDate>Mon, 22 Feb 2021 00:00:00 +0000</pubDate><author>Lorenzo Girardi</author><guid>https://www.k8s.it/posts/kubernetes-nstats/</guid><description><![CDATA[<div class="featured-image">
                <img src="/images/kubernetes-nstats/Screenshot-2021-02-22-at-18.16.33.png" referrerpolicy="no-referrer">
            </div><p></p>
<p>Here we go&hellip; another weird sidecar container.</p>
<h2 id="motivations">Motivations</h2>
<p>I&rsquo;ve always been interested in the observability area. There are many aspects that improve performances and fix bugs. One of the most interesting is network usage.</p>
<p>This is not about network issues:</p>
<p></p>
<p>It&rsquo;s about understanding <em>where</em> bandwidth is actually going.</p>
<p>You&rsquo;re probably used to seeing something like this for your VMs:</p>]]></description></item><item><title>Docker-latency — The Network Blaming Tool</title><link>https://www.k8s.it/posts/docker-latency/</link><pubDate>Tue, 11 Aug 2020 00:00:00 +0000</pubDate><author>Lorenzo Girardi</author><guid>https://www.k8s.it/posts/docker-latency/</guid><description><![CDATA[<div class="featured-image">
                <img src="/images/docker-latency/grafana_home.png" referrerpolicy="no-referrer">
            </div><h2 id="aka-the-network-blaming-tool">aka the network blaming tool</h2>
<p>Every network admin hears it. &ldquo;The VPN is slow.&rdquo; &ldquo;I can&rsquo;t connect to $something.&rdquo; &ldquo;It worked yesterday.&rdquo;</p>
<p>The problem: these complaints are vague. Is it the provider? A T2/T3 routing issue? The user&rsquo;s local network? Without data, you&rsquo;re guessing.</p>
<p>This tool collects data.</p>
<h2 id="how-to-understand-if-your-network-is-really-slow">How to Understand if Your Network is Really Slow</h2>
<p>Deploy a pre-configured Grafana stack that monitors internet connection statistics. Select the endpoints that matter — VPN gateways, datacenter public IPs, main DNS servers — and get a continuous picture of latency and packet loss.</p>]]></description></item><item><title>Kubernetes Service Mesh</title><link>https://www.k8s.it/posts/kubernetes-servicemesh/</link><pubDate>Tue, 11 Aug 2020 00:00:00 +0000</pubDate><author>Lorenzo Girardi</author><guid>https://www.k8s.it/posts/kubernetes-servicemesh/</guid><description><![CDATA[<div class="featured-image">
                <img src="/images/kubernetes-servicemesh/img_flow.png" referrerpolicy="no-referrer">
            </div><p></p>
<p>Do we need a service mesh? A few years ago I started evaluating this feature for existing infrastructure. There are many concepts to consider, and many mistakes people commonly make in thinking about what service mesh does.</p>
<p>Better to start with what a service mesh is <strong>NOT</strong>.</p>
<h2 id="what-a-service-mesh-is-not">What a Service Mesh Is NOT</h2>
<ul>
<li>Not an API gateway (though they may share some components)</li>
<li>Not the location for firewall rules</li>
<li>Not a magical application performance booster</li>
<li>Not something to add without a clear scope — if you do, it could create disorder</li>
</ul>
<h2 id="what-a-service-mesh-is">What a Service Mesh IS</h2>
<p>The short answer covers four areas:</p>]]></description></item></channel></rss>