-
Notifications
You must be signed in to change notification settings - Fork 1
/
index.xml
256 lines (224 loc) · 30 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
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>OpenELB – OpenELB</title>
<link>/</link>
<description>Recent content on OpenELB</description>
<generator>Hugo -- gohugo.io</generator>
<atom:link href="/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Blog: PorterLB: High Availability Mechanisms in Layer 2 Mode</title>
<link>/blog/2021/03/30/porterlb-high-availability-mechanisms-in-layer-2-mode/</link>
<pubDate>Tue, 30 Mar 2021 00:00:00 +0000</pubDate>
<guid>/blog/2021/03/30/porterlb-high-availability-mechanisms-in-layer-2-mode/</guid>
<description>
<p>PorterLB makes it possible for users to expose Services in bare-metal Kubernetes environments. Currently, PorterLB supports the BGP mode and the Layer 2 mode, which use BGP and ARP/NDP respectively to expose Services.</p>
<p>Generally, the BGP mode is recommended because it allows you to build a high availability system free of failover interruptions and bandwidth bottlenecks. However, BGP may be unavailable in certain systems because of security requirements or because the router does not support BGP. In this case, you can use PorterLB in Layer 2 mode to achieve similar functionality.</p>
<p>Though the Layer 2 mode does not provide the same high availability as the BGP mode, it does implement certain mechanisms to ensure that PorterLB can still function as long as the Kubernetes cluster is not entirely down.</p>
<p>In this article, I am going to discuss the high availability mechanisms of PorterLB in Layer 2 mode. The following scenarios will be examined:</p>
<ul>
<li>Scenario 1: Only one PorterLB replica is deployed and the node selected by PorterLB is down.</li>
<li>Scenario 2: Only one PorterLB replica is deployed and the node that hosts PorterLB is down.</li>
<li>Scenario 3: Multiple PorterLB replicas are deployed and one of the nodes that contain PorterLB replicas is down.</li>
</ul>
<h2 id="scenario-1-the-next-hop-is-down">Scenario 1: The Next Hop Is Down</h2>
<img src="/images/blog/porterlb-high-availability-mechanisms-in-layer-2-mode/scenario-1-1.png" width="800px">
<p>In the Kubernetest cluster, only one PorterLB replica (porter-manager Pod) is deployed on node 3 and an application Pod is deployed on node 2. The application Pod is exposed by using a Service (192.168.0.91). PorterLB maps the IP address of the Service to the MAC address of node 2.</p>
<p>If the node (node 2 in this example) selected by PorterLB is down, PorterLB automatically maps the Service IP address to the MAC address of another node to rebuild connection to the Service.</p>
<p>Therefore, the network topology after node 2 is down probably looks like the following:</p>
<img src="/images/blog/porterlb-high-availability-mechanisms-in-layer-2-mode/scenario-1-2.png" width="800px">
<p>One thing you should be aware of is that although PorterLB automatically rebuilds the connection to the Service, there is a short period of failover interruption, which is one of the reasons why the BGP mode better suits scenarios where availability is vital.</p>
<h2 id="scenario-2-the-only-porterlb-node-is-down">Scenario 2: The Only PorterLB Node Is Down</h2>
<img src="/images/blog/porterlb-high-availability-mechanisms-in-layer-2-mode/scenario-2-1.png" width="800px">
<p>So what if the node that hosts the porter-manager Pod is down?</p>
<p>Well, the porter-manager Pod is deployed under a ReplicaSet in a Deployment. Therefore, if the node that hosts the porter-manager Pod is down, the Kubernetes system automatically re-creates the porter-manager Pod on another node. The network topology changes to the following:</p>
<img src="/images/blog/porterlb-high-availability-mechanisms-in-layer-2-mode/scenario-2-2.png" width="800px">
<p>Though existing Services that use PorterLB are not affected, the functionality of PorterLB is unavailable during the re-creation, which is why you are advised to deploy multiple PorterLB replicas (porter-manager Pods) in the cluster.</p>
<h2 id="scenario-3-one-of-multiple-porterlb-nodes-is-down">Scenario 3: One of Multiple PorterLB Nodes Is Down</h2>
<img src="/images/blog/porterlb-high-availability-mechanisms-in-layer-2-mode/scenario-3-1.png" width="800px">
<p>When multiple PorterLB replicas (porter-manager Pods) are deployed, PorterLB uses the leader election mechanism to ensure that only one replica (the leader) communicates with the router. If the node that hosts the leader is down, another PorterLB replica automatically takes over the service after a leader re-election. The network topology changes to the following:</p>
<img src="/images/blog/porterlb-high-availability-mechanisms-in-layer-2-mode/scenario-3-2.png" width="800px">
<p>Although the functionality of PorterLB is still unavailable during the leader re-election, the downtime is much shorter than that in scenario 2. Therefore, if you need to use the Layer 2 mode in a production environment, it is highly recommended that you deploy multiple PorterLB replicas to improve the availability.</p>
</description>
</item>
<item>
<title>Blog: KubeSphere+PorterLB: Implement Grayscale Release on Bare-Metal Kubernetes</title>
<link>/blog/2021/03/12/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/</link>
<pubDate>Fri, 12 Mar 2021 00:00:00 +0000</pubDate>
<guid>/blog/2021/03/12/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/</guid>
<description>
<p><a href="https://porterlb.io">PorterLB</a> is a load balancer implementation designed for bare-metal Kubernetes clusters. As a sub-project of <a href="https://kubesphere.io">KubeSphere</a>, PorterLB fits well into the KubeSphere ecosystem. You can seamlessly integrate PorterLB as a plugin with KubeSphere to utilize the abundant features of the KubeSphere ecosystem.</p>
<p>During new feature release, the KubeSphere grayscale release feature allows users to freely distribute traffic among a stable version and a beta version of an application to both ensure service continuity and test the beta version before formally rolling it out.</p>
<p>In this article, I am going to introduce how to use KubeSphere and PorterLB to implement grayscale release for an application in a bare-metal Kubernetes cluster. To make you quickly understand how it works, I am going to directly use demonstration settings without digging too much into the details. You can obtain detailed guidance from the <a href="https://kubesphere.io/docs/">KubeSphere documentation</a> and <a href="https://porterlb.io/docs/">PorterLB documentation</a>.</p>
<h2 id="architecture">Architecture</h2>
<p><img src="/images/en/blog/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/architecture.png" alt="architecture"></p>
<ul>
<li>
<p>Grayscale release</p>
<p>In the preceding figure, an application Service backed by Pod v1 (stable version) is deployed in a Kubernetes cluster. After grayscale release is configured on KubeSphere, Pod v2 (beta version) is created and users can determine how much traffic is forwarded to Pod v1 and how much to Pod v2. After Pod v2 is fully tested, Pod v1 can be taken offline and Pod v2 will take over all traffic.</p>
</li>
<li>
<p>KubeSphere gateway</p>
<p>The application Service is exposed to the outside by using the KubeSphere gateway, which is in effect a Service backed by a Pod that functions as a reverse proxy. An external client uses a path of a domain name to access the application Service. The reverse proxy Pod obtains the mapping between the path and the application Service from a Route object.</p>
</li>
<li>
<p>PorterLB</p>
<p>PorterLB installed in the Kubernetes cluster sends an ARP packet to the router, and tells the router to forward traffic destined for the gateway Service to node 1. If node 1 fails, the traffic will be forwarded to node 2.</p>
</li>
</ul>
<h2 id="procedure">Procedure</h2>
<h3 id="prerequisites">Prerequisites</h3>
<ul>
<li>You need to prepare a Kubernetes cluster, and install <a href="https://kubesphere.io/docs/installing-on-kubernetes/">KubeSphere</a> and <a href="https://porterlb.io/docs/getting-started/installation/">PorterLB</a> in the Kubernetes cluster.</li>
<li>On KubeSphere, you need to <a href="https://kubesphere.io/docs/quick-start/create-workspace-and-project/">create a project and an account</a>. The role of the account in the project must be <code>project-admin</code>.</li>
</ul>
<h3 id="operations">Operations</h3>
<p>Step 1: Set the KubeSphere gateway to use PorterLB and create an Eip object.</p>
<ol>
<li>
<p>Log in to KubeSphere and go to your project.</p>
</li>
<li>
<p>Choose <strong>Project Settings</strong> &gt; <strong>Advanced Settings</strong> on the left navigation bar and click <strong>Set Gateway</strong> on the right.</p>
</li>
<li>
<p>Click <strong>LoadBalancer</strong>, set <strong>Application Governance</strong> to <strong>On</strong>, add the following annotations, and click <strong>Save</strong>. The annotations set the KubeSphere gateway Service to use PorterLB in Layer 2 mode.</p>
<div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">lb.kubesphere.io/v1alpha1</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>porter<span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">protocol.porter.kubesphere.io/v1alpha1</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>layer2<span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">eip.porter.kubesphere.io/v1alpha2</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>porter-layer2-eip<span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#8f5902;font-style:italic"># Name of the Eip object.</span><span style="color:#f8f8f8;text-decoration:underline">
</span></code></pre></div></li>
<li>
<p>Move the cursor to <img src="/images/en/blog/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/kubectl.png" width="25px"> in the lower-right corner and click <strong>Kubectl</strong> to open the CLI.</p>
</li>
<li>
<p>Run the <code>vi porter-layer2-eip.yaml</code> command to create a YAML file for an Eip object and add the following information to the YAML file:</p>
<div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-yaml" data-lang="yaml"><span style="color:#204a87;font-weight:bold">apiVersion</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>network.kubesphere.io/v1alpha2<span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">kind</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>Eip<span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">metadata</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">name</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>porter-layer2-eip<span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"></span><span style="color:#204a87;font-weight:bold">spec</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#8f5902;font-style:italic"># Use an unoccupied address on the same network segment as your K8s cluster.</span><span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">address</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#0000cf;font-weight:bold">192.168.0.100</span><span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">interface</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>eth0<span style="color:#f8f8f8;text-decoration:underline">
</span><span style="color:#f8f8f8;text-decoration:underline"> </span><span style="color:#204a87;font-weight:bold">protocol</span><span style="color:#000;font-weight:bold">:</span><span style="color:#f8f8f8;text-decoration:underline"> </span>layer2<span style="color:#f8f8f8;text-decoration:underline">
</span></code></pre></div></li>
<li>
<p>Run the <code>kubectl apply -f eip.yaml</code> command to create the Eip object, which functions as an IP address pool for PorterLB.</p>
</li>
</ol>
<p>Step 2: Create an application.</p>
<ol>
<li>Choose <strong>Application Workloads</strong> on the left navigation bar and click <strong>Create Composing Application</strong> on the right.</li>
<li>Set <strong>Application Name</strong> to <strong>demo-app</strong>, <strong>Application Version(Optional)</strong> to <strong>v1</strong>, <strong>Application Governance</strong> to <strong>On</strong>, and click <strong>Next</strong>.</li>
<li>Click <strong>Add Service</strong>, click <strong>Stateless Service</strong>, set <strong>Name</strong> to <code>demo-svc</code>, and click <strong>Next</strong>.</li>
<li>Click <strong>Add Container Image</strong>, set <strong>Image</strong> to <code>luksa/kubia</code>, <strong>Container Port</strong> to <code>8080</code>, <strong>Service Port</strong> to <code>80</code>, click <strong>√</strong>, and click <strong>Next</strong>.</li>
<li>Click <strong>Next</strong> on the <strong>Mount Volumes</strong> tab, click <strong>Add</strong> on the <strong>Advanced Settings</strong> tab, and click <strong>Next</strong>.</li>
<li>Click <strong>Add Route Rule</strong>, click <strong>Specify Domain</strong>, set <strong>HostName</strong> to <code>demo.com</code>, <strong>Paths</strong> to <code>/path | demo-svc | 80</code>, and click <strong>OK</strong>.</li>
<li>Click <strong>Create</strong>.</li>
</ol>
<p>Step 3: Configure grayscale release.</p>
<ol>
<li>Choose <strong>Grayscale Release</strong> on the left navigation bar, move the cursor to <strong>Canary Release</strong>, and click <strong>Create Job</strong>.</li>
<li>Set <strong>Release Job Name</strong> to <code>demo-canary</code> and click <strong>Next</strong>.</li>
<li>Select <code>demo-app</code> from the drop-down list, click <strong>Select</strong> on the right of <strong>demo-svc</strong>, and click <strong>Next</strong>.</li>
<li>Set <strong>Grayscale Release Version Number</strong> to <code>v2</code> and click <strong>Next</strong>.</li>
<li>Click <strong>Create</strong> on the <strong>Policy Config</strong> tab.</li>
</ol>
<p>Step 4: Test grayscale release.</p>
<ol>
<li>
<p>Choose <strong>Grayscale Release</strong> on the left navigation bar, click the <strong>Job Status</strong> tab, and click <strong>demo-canary</strong> on the right.</p>
</li>
<li>
<p>In the <strong>Real-time traffic distribution</strong> area, move the slider so that 100% traffic is sent to v2.</p>
</li>
<li>
<p>Log in to a client machine connected to the gateway Service IP address (configured in the Eip object) and add the domain name information to the <code>etc/hosts</code> file:</p>
<div class="highlight"><pre style="background-color:#f8f8f8;-moz-tab-size:4;-o-tab-size:4;tab-size:4"><code class="language-bash" data-lang="bash">192.168.0.100 demo.com
</code></pre></div></li>
<li>
<p>On the client machine, run the <code>curl demo.com/path</code> command for multiple times to access the application Service.</p>
<p>If grayscale release functions properly, only v2 can be accessed.</p>
<img src="/images/en/blog/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/v2.png" width="600px">
</li>
<li>
<p>On KubeSphere, repeat step 2 so that 100% traffic is sent to v1.</p>
</li>
<li>
<p>On the client machine, run the <code>curl demo.com/path</code> command for multiple times to access the application Service.</p>
<p>If grayscale release functions properly, only v1 can be accessed.</p>
<img src="/images/en/blog/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/v1.png" width="600px">
</li>
<li>
<p>After v2 is fully tested, you can set v2 to take over all traffic and take the canary release job offline to formally release v2.</p>
<img src="/images/en/blog/kubesphere-porterlb-implement-grayscale-release-on-bare-metal-kubernetes/job-offline.png">
</li>
</ol>
</description>
</item>
<item>
<title>Blog: PorterLB for Bare-Metal Kubernetes: Cloud Native, Elegant, and Flexible</title>
<link>/blog/2021/02/25/porterlb-for-bare-metal-kubernetes-cloud-native-elegant-and-flexible/</link>
<pubDate>Thu, 25 Feb 2021 00:00:00 +0000</pubDate>
<guid>/blog/2021/02/25/porterlb-for-bare-metal-kubernetes-cloud-native-elegant-and-flexible/</guid>
<description>
<p>Applications deployed on Kubernetes are usually exposed by using LoadBalancer Services, which rely heavily on load balancer implementations provided by cloud vendors. For applications deployed in bare-metal Kubernetes clusters, where cloud-based load balancer implementations are unavailable, Kubernetes has yet to provide a viable LoadBalancer solution.</p>
<p>PorterLB well addresses this problem. As a sub-project of <a href="https://kubesphere.io/">KubeSphere</a>, PorterLB boosts application containerization in bare-metal Kubernetes environments, and complements the KubeSphere ecosystem in the bare-metal field.</p>
<p>In this article, I am going to introduce how PorterLB functions in Layer 2 mode and BGP mode, which are provided for users to expose applications in different scenarios, and the advantages of PorterLB compared with other bare-metal load balancer implementations such as MetalLB.</p>
<h2 id="bgp-mode">BGP Mode</h2>
<p>In BGP mode, PorterLB publishes routes to a BGP router deployed outside the Kubernetes cluster, and the BGP router forwards Service traffic from external clients to the Kubernetes cluster nodes based on the routes obtained from PorterLB. In this process, PorterLB uses Equal-Cost Multi-Path (ECMP) routing to ensure that all Kubernetes nodes or nodes that contain Pods, depending on the user configuration, are used as next hops by the BGP router.</p>
<p><img src="/images/en/blog/porterlb-for-bare-metal-kubernetes-cloud-native-elegant-and-flexible/porter-bgp-topology.jpg" alt="porter-bgp-topology"></p>
<p>The process of using PorterLB in BGP mode in a Kubernetes cluster is simple:</p>
<ol>
<li>Install PorterLB.</li>
<li>Configure an IP address pool by using Eip.</li>
<li>Configure BGP properties by using BgpConf and BgpPeer.</li>
<li>Create a Service and set the Service to use PorterLB, which is similar to what you do to use a load balancer plugin in a cloud-based Kubernetes cluster.</li>
</ol>
<p>PorterLB can be configured by using the Eip, BgpConf, and BgpPeer CRDs, no other configuration files are required. In addition, as BGP is decentralized, you can use the BGP mode to easily establish a high availability network free of failover interruptions and bandwidth bottlenecks.</p>
<p><img src="/images/en/blog/porterlb-for-bare-metal-kubernetes-cloud-native-elegant-and-flexible/high-availability-network.jpg" alt="high-availability-network"></p>
<h2 id="layer-2-mode">Layer 2 Mode</h2>
<p>Generally, you are advised to use the BGP mode to expose your Services in a high availability network. However, BGP may be unavailable in certain systems because of security requirements or because the router does not support BGP. In this case, you can use PorterLB in Layer 2 mode to achieve similar functionality.</p>
<p>In Layer 2 mode, PorterLB uses ARP packets (for IPv4) or NDP packets (for IPv6) to map the Service IP address to the MAC address of a Kubernetes node. The mechanism of the Layer 2 mode is similar to that of the BGP mode, except that BGP is replaced with ARP/NDP and the router obtains only one route destined for the Service.</p>
<p><img src="/images/en/blog/porterlb-for-bare-metal-kubernetes-cloud-native-elegant-and-flexible/porter-layer-2-topology.jpg" alt="porter-layer-2-topology"></p>
<p>Though the Layer 2 mode does not provide the same high availability as the BGP mode does, it is easier to use (you don&rsquo;t even need to configure BGP properties):</p>
<ol>
<li>Install PorterLB.</li>
<li>Configure an IP address pool by using Eip.</li>
<li>Create a Service and set the Service to use PorterLB.</li>
</ol>
<p>You can obtain detailed guidance on how to install, configure, and use PorterLB from the <a href="https://porterlb.io/docs/">PorterLB documentation</a>.</p>
<h2 id="advantages-of-porterlb">Advantages of PorterLB</h2>
<p>There are other load balancer implementations such as MetalLB designed for bare-metal Kubernetes clusters. Compared with others, PorterLB has the following advantages.</p>
<h3 id="cloud-native">Cloud native</h3>
<p>To manage IP address pools and BGP properties for PorterLB, you only need to use the <code>kubectl apply</code> command provided by Kubernetes to create CRD objects. To obtain the status information about IP address pools and BGP peers, you can simply run <code>kubectl get</code> to view the status of the CRD objects. No other configuration files are required. In addition, a PorterLB GUI will be available soon, which will further simplify the usage of PorterLB.</p>
<h3 id="elegant">Elegant</h3>
<p>After PorterLB is installed in a Kubernetes cluster, a porter-manager Deployment that contains a porter-manager Pod is created. The porter-manager Pod implements the functionality of PorterLB for the entire Kubernetes cluster. For high availability, you can scale the porter-manager Deployment and assign multiple PorterLB replicas (porter-manager Pods) to multiple cluster nodes. This simple architecture ensures that PorterLB can be easily managed and integrated with other systems.</p>
<h3 id="flexible">Flexible</h3>
<p>PorterLB can be used in conventional Kubernetes clusters. As a sub-project of KubeSphere, PorterLB also fits well into the KubeSphere ecosystem. You can seamlessly integrate PorterLB as a plugin with KubeSphere to utilize the abundant features of the KubeSphere ecosystem, such as observability and troubleshooting, unified monitoring and logging, centralized storage and networking management, and easy-to-use CI/CD pipelines.</p>
</description>
</item>
<item>
<title>Blog: An Open-Source Load Balancer for Bare-Metal Kubernetes</title>
<link>/blog/2019/06/24/an-open-source-load-balancer-for-bare-metal-kubernetes/</link>
<pubDate>Mon, 24 Jun 2019 00:00:00 +0000</pubDate>
<guid>/blog/2019/06/24/an-open-source-load-balancer-for-bare-metal-kubernetes/</guid>
<description>
<p>As we know, the backend workload can be exposed externally using service of type &ldquo;LoadBalancer&rdquo; in Kubernetes cluster. Cloud vendors often provide cloud LB plugins for Kubernetes which requires the cluster to be deployed on a specific IaaS platform. However, many enterprise users usually deploy Kubernetes clusters on bare meta especially for production use. For the on-premise bare meta clusters, Kubernetes does not provide Load-Balancer implementation. PorterLB, an open-source project, is the right solution for such issue.</p>
<p>This video will focus on the network technologies to help expose service and EIP management for bare meta Kubernetes cluster.</p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/EjU1yAVxXYQ" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
</description>
</item>
<item>
<title>Blog: The Interview to PorterLB from The New Stack</title>
<link>/blog/2019/06/24/the-interview-to-porterlb-from-the-new-stack/</link>
<pubDate>Mon, 24 Jun 2019 00:00:00 +0000</pubDate>
<guid>/blog/2019/06/24/the-interview-to-porterlb-from-the-new-stack/</guid>
<description>
<p>On this livestream from KubeCon + CloudNativeCon China, Alex Williams was sitting down with Xuetao Song, Senior Software Engineer at Beijing Yunify Technology Co., Ltd. and Fang (Flora) Du, QingCloud Solution Architect at Beijing Yunify Technology Co., Ltd. to discuss open source load balancing on bare metal. PorterLB exists as an OSS solution to the issue of load balancing on bare metal in production on Kubernetes, which Song and Du are giving a presentation on at KCCNC + OSS Summit China 2019.</p>
<iframe width="560" height="315" src="https://www.youtube.com/embed/zSWypFKaYcY" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
<h2 id="related-post">Related Post</h2>
<p>Please reference <a href="https://thenewstack.io/how-a-china-based-bare-metal-service-provider-tackled-kubernetes-load-balancing/">How a China-Based Bare Metal Service Provider Tackled Kubernetes Load Balancing</a> for details.</p>
</description>
</item>
</channel>
</rss>