<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Ingress-Controller on The IT Hollow</title>
    <link>https://theithollow.com/tags/ingress-controller/</link>
    <description>Recent content in Ingress-Controller on The IT Hollow</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Wed, 13 Feb 2019 15:00:46 +0000</lastBuildDate>
    <atom:link href="https://theithollow.com/tags/ingress-controller/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Kubernetes - Ingress</title>
      <link>https://theithollow.com/2019/02/13/kubernetes-ingress/</link>
      <pubDate>Wed, 13 Feb 2019 15:00:46 +0000</pubDate>
      <guid>https://theithollow.com/2019/02/13/kubernetes-ingress/</guid>
      <description>&lt;p&gt;It&amp;rsquo;s time to look closer at how we access our containers from outside the Kubernetes cluster. We&amp;rsquo;ve talked about Services with NodePorts, LoadBalancers, etc., but a better way to handle ingress might be to use an ingress-controller to proxy our requests to the right backend service. This post will take us through how to integrate an ingress-controller into our Kubernetes cluster.&lt;/p&gt;
&lt;h2 id=&#34;ingress-controllers---the-theory&#34;&gt;Ingress Controllers - The Theory&lt;/h2&gt;
&lt;p&gt;Lets first talk about why we&amp;rsquo;d want to use an ingress controller in the first place. Take an example web application like you might have for a retail store. That web application might have an index page at &amp;ldquo;&lt;a href=&#34;http://store-name.com/%22&#34;&gt;http://store-name.com/&amp;quot;&lt;/a&gt; and a shopping cart page at &amp;ldquo;&lt;a href=&#34;http://store-name.com/cart%22&#34;&gt;http://store-name.com/cart&amp;quot;&lt;/a&gt; and an api URI at &amp;ldquo;&lt;a href=&#34;http://store-name.com/api%22&#34;&gt;http://store-name.com/api&amp;quot;&lt;/a&gt;. We could build all these in a single container, but perhaps each of those becomes their own set of pods so that they can all scale out independently. If the API needs more resources, we can just increase the number of pods and nodes for the api service and leave the / and the /cart services alone. It also allows for multiple groups to work on different parts simultaneously but we&amp;rsquo;re starting to drift off the point which hopefully you get now.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
