DevFW-CICD/ingress-nginx-helm
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Deploy GitHub Pages

Browse source
This commit is contained in:
Travis Bot 2019-11-08 19:24:34 +00:00
parent bc6e898a19
commit cf75938808
56 changed files with 483 additions and 475 deletions
Download patch file Download diff file Expand all files Collapse all files

12
deploy/baremetal/index.html
View file

@ -1249,7 +1249,7 @@
<a href="https://github.com/kubernetes/ingress-nginx/edit/master/docs/deploy/baremetal.md" title="Edit this page" class="md-icon md-content__icon">&#xE3C9;</a>
<h1 id="bare-metal-considerations">Bare-metal considerations<a class="headerlink" href="#bare-metal-considerations" title="Permanent link">&para;</a></h1>
<h1 id="bare-metal-considerations">Bare-metal considerations<a class="headerlink" href="#bare-metal-considerations" title="Permanent link"></a></h1>
<p>In traditional <em>cloud</em> environments, where network load balancers are available on-demand, a single Kubernetes manifest
suffices to provide a single point of contact to the NGINX Ingress controller to external clients and, indirectly, to
any application running inside the cluster. <em>Bare-metal</em> environments lack this commodity, requiring a slightly
@ -1258,7 +1258,7 @@ different setup to offer the same kind of access to external consumers.</p>
<img alt="Bare-metal environment" src="../../images/baremetal/baremetal_overview.jpg" /></p>
<p>The rest of this document describes a few recommended approaches to deploying the NGINX Ingress controller inside a
Kubernetes cluster running on bare-metal.</p>
<h2 id="a-pure-software-solution-metallb">A pure software solution: MetalLB<a class="headerlink" href="#a-pure-software-solution-metallb" title="Permanent link">&para;</a></h2>
<h2 id="a-pure-software-solution-metallb">A pure software solution: MetalLB<a class="headerlink" href="#a-pure-software-solution-metallb" title="Permanent link"></a></h2>
<p><a href="https://metallb.universe.tf/">MetalLB</a> provides a network load-balancer implementation for Kubernetes clusters that do not run on a
supported cloud provider, effectively allowing the usage of LoadBalancer Services within any cluster.</p>
<p>This section demonstrates how to use the <a href="https://metallb.universe.tf/tutorial/layer2/">Layer 2 configuration mode</a> of MetalLB together with the NGINX
@ -1328,7 +1328,7 @@ the ports configured in the LoadBalancer Service:</p>
traffic policy. Traffic policies are described in more details in <a href="https://metallb.universe.tf/usage/#traffic-policies">Traffic policies</a> as
well as in the next section.</p>
</div>
<h2 id="over-a-nodeport-service">Over a NodePort Service<a class="headerlink" href="#over-a-nodeport-service" title="Permanent link">&para;</a></h2>
<h2 id="over-a-nodeport-service">Over a NodePort Service<a class="headerlink" href="#over-a-nodeport-service" title="Permanent link"></a></h2>
<p>Due to its simplicity, this is the setup a user will deploy by default when following the steps described in the
<a href="../#bare-metal">installation guide</a>.</p>
<div class="admonition info">
@ -1469,7 +1469,7 @@ NodePort:</p>
</pre></div>
</div>
<h2 id="via-the-host-network">Via the host network<a class="headerlink" href="#via-the-host-network" title="Permanent link">&para;</a></h2>
<h2 id="via-the-host-network">Via the host network<a class="headerlink" href="#via-the-host-network" title="Permanent link"></a></h2>
<p>In a setup where there is no external load balancer available but using NodePorts is not an option, one can configure
<code class="codehilite">ingress-nginx</code> Pods to use the network of the host they run on instead of a dedicated network namespace. The benefit of
this approach is that the NGINX Ingress controller can bind ports 80 and 443 directly to Kubernetes nodes' network
@ -1566,7 +1566,7 @@ address of all nodes running the NGINX Ingress controller.</p>
<p>Alternatively, it is possible to override the address written to Ingress objects using the
<code class="codehilite">--publish-status-address</code> flag. See <a href="../../user-guide/cli-arguments/">Command line arguments</a>.</p>
</div>
<h2 id="using-a-self-provisioned-edge">Using a self-provisioned edge<a class="headerlink" href="#using-a-self-provisioned-edge" title="Permanent link">&para;</a></h2>
<h2 id="using-a-self-provisioned-edge">Using a self-provisioned edge<a class="headerlink" href="#using-a-self-provisioned-edge" title="Permanent link"></a></h2>
<p>Similarly to cloud environments, this deployment approach requires an edge network component providing a public
entrypoint to the Kubernetes cluster. This edge component can be either hardware (e.g. vendor appliance) or software
(e.g. <em>HAproxy</em>) and is usually managed outside of the Kubernetes landscape by operations teams.</p>
@ -1577,7 +1577,7 @@ This is particularly suitable for private Kubernetes clusters where none of the
nodes and/or masters. Incoming traffic on TCP ports 80 and 443 is forwarded to the corresponding HTTP and HTTPS NodePort
on the target nodes as shown in the diagram below:</p>
<p><img alt="User edge" src="../../images/baremetal/user_edge.jpg" /></p>
<h2 id="external-ips">External IPs<a class="headerlink" href="#external-ips" title="Permanent link">&para;</a></h2>
<h2 id="external-ips">External IPs<a class="headerlink" href="#external-ips" title="Permanent link"></a></h2>
<div class="admonition danger">
<p class="admonition-title">Source IP address</p>
<p>This method does not allow preserving the source IP of HTTP requests in any manner, it is therefore <strong>not