-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathindex.xml
83 lines (73 loc) · 7.01 KB
/
index.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title></title>
<link>https://cloudnativelabs.github.io/</link>
<description>Recent content on </description>
<generator>Hugo -- gohugo.io</generator>
<managingEditor>[email protected] (Cloudnative Labs)</managingEditor>
<webMaster>[email protected] (Cloudnative Labs)</webMaster>
<lastBuildDate>Wed, 01 Nov 2017 00:00:00 +0000</lastBuildDate>
<atom:link href="https://cloudnativelabs.github.io/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Kube-router: Highly-available and scalable ingress for baremetal Kubernetes clusters</title>
<link>https://cloudnativelabs.github.io/post/2017-11-01-kube-high-available-ingress/</link>
<pubDate>Wed, 01 Nov 2017 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/post/2017-11-01-kube-high-available-ingress/</guid>
<description>Over the years many webscale companies have designed massivley scalable and highly available services using loadbalancer solutions based on commodity Linux servers. Traditional middleboxes are completely replaced with software loadbalancers. In this blog we will see common building blocks across Microsoft&rsquo;s Ananta, Google&rsquo;s Maglev, Facebook&rsquo;s Shiv, Github GLB and Yahoo L3 DSR. We will see how Kube-router has implemented some of these building blocks for Kuberentes, and how you can leverage them to build a highly-available and scalable ingress in bare-metal deployments.</description>
</item>
<item>
<title>Kube-router: Kubernetes pod networking and beyond with BGP</title>
<link>https://cloudnativelabs.github.io/post/2017-05-22-kube-pod-networking/</link>
<pubDate>Mon, 22 May 2017 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/post/2017-05-22-kube-pod-networking/</guid>
<description>In earlier blog on Kubernetes networking we have seen how Kubernetes is non-prescriptive of how the network should be designed for running pods. There can be multiple way to design the network that meets Kubernetes networking requirements with varying degree of complexity, flexibility. In this blog we will see how Kube-router implements a pure L3 solution for cross node pod-to-pod networking using BGP and see how use of BGP gives unique advantage which enables pod IP and Kubernetes service cluster IP to be routable from out side of the cluster.</description>
</item>
<item>
<title>Kube-router: Kubernetes network services proxy with IPVS/LVS</title>
<link>https://cloudnativelabs.github.io/post/2017-05-10-kube-network-service-proxy/</link>
<pubDate>Fri, 12 May 2017 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/post/2017-05-10-kube-network-service-proxy/</guid>
<description>A Kubernetes Service is an abstraction which groups a logical set of Pods that provide the same functionality. A service in Kubernetes can be of different types, of which &lsquo;ClusterIP&rsquo; and &lsquo;NodePort&rsquo; types forms basis for service discovery and load balancing. Both of the service types requires a service proxy running on each of the cluster node. Kubernetes has an implementation of service proxy &lsquo;Kube-proxy&rsquo; based on iptables. While Kube-proxy provides out-of-box solution its not necessarily an optimal solution for all users.</description>
</item>
<item>
<title>Kube-router: Enforcing Kubernetes network policies with iptables and ipset</title>
<link>https://cloudnativelabs.github.io/post/2017-05-1-kube-network-policies/</link>
<pubDate>Wed, 03 May 2017 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/post/2017-05-1-kube-network-policies/</guid>
<description>Network policies in Kubernetes provides primary means to secure a pod by exerting control over who can connect to pod. Intent of this blog post is not to describe what network policies are but to show how iptables on the the cluster nodes can be used to build a distributed firewall solution that enforces network policies in Kubernetes clusters. This write up draws up from the insights of implementing a network policy controller in Kube-router.</description>
</item>
<item>
<title>Kube-router</title>
<link>https://cloudnativelabs.github.io/post/2017-04-19-kube-router/</link>
<pubDate>Wed, 19 Apr 2017 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/post/2017-04-19-kube-router/</guid>
<description>In previous blog we went over the Kubernetes service discovery, load balancing and network policies. In this blog we will use Kube-router a distributed load balancer, firewall and router for Kubernetes and demonstrate the Kubernetes networking constructs in action.
We will setup a Kubernetes cluster from scratch and use kube-router instead of kube-proxy and demonstrate how kube-router provides a solution for cross-node pod-to-pod networking, provides a service proxy on each node and load balances the traffic.</description>
</item>
<item>
<title>Kubernetes Networking</title>
<link>https://cloudnativelabs.github.io/post/2017-04-18-kubernetes-networking/</link>
<pubDate>Tue, 18 Apr 2017 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/post/2017-04-18-kubernetes-networking/</guid>
<description>This article gives brief overview of fundamnetal networking concepts in Kubernetes.
First thing one notices with Kubernetes in comparision to other container orchestration platforms is container itself is not a first class construct in Kubernetes. Containers always exists in the context of pod. So first lets understand the basic Kubernetes building block Pod that consumes network. A pod is a group of one or more containers that are always co-located and co-scheduled, and run in a shared context.</description>
</item>
<item>
<title>About me</title>
<link>https://cloudnativelabs.github.io/page/about/</link>
<pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
<author>[email protected] (Cloudnative Labs)</author>
<guid>https://cloudnativelabs.github.io/page/about/</guid>
<description>My name is Inigo Montoya. I have the following qualities:
I rock a great mustache I&rsquo;m extremely loyal to my family What else do you need?
my history To be honest, I&rsquo;m having some trouble remembering right now, so why don&rsquo;t you just watch my movie and it will answer all your questions.</description>
</item>
</channel>
</rss>