Deploy GitHub Pages
This commit is contained in:
parent
4d834d65e9
commit
aaf1debd0f
3 changed files with 54 additions and 50 deletions
|
@ -1200,16 +1200,20 @@
|
|||
<h2 id="nginx-configuration">NGINX configuration<a class="headerlink" href="#nginx-configuration" title="Permanent link">¶</a></h2>
|
||||
<p>The goal of this Ingress controller is the assembly of a configuration file (nginx.conf). The main implication of this requirement is the need to reload NGINX after any change in the configuration file. <em>Though it is important to note that we don't reload Nginx on changes that impact only an <code class="codehilite">upstream</code> configuration (i.e Endpoints change when you deploy your app)</em>. We use https://github.com/openresty/lua-nginx-module to achieve this. Check <a href="#avoiding-reloads-on-endpoints-changes">below</a> to learn more about how it's done.</p>
|
||||
<h2 id="nginx-model">NGINX model<a class="headerlink" href="#nginx-model" title="Permanent link">¶</a></h2>
|
||||
<p>Usually, a Kubernetes Controller utilizes the <a href="1">synchronization loop pattern</a> to check if the desired state in the controller is updated or a change is required. To this purpose, we need to build a model using different objects from the cluster, in particular (in no special order) Ingresses, Services, Endpoints, Secrets, and Configmaps to generate a point in time configuration file that reflects the state of the cluster.</p>
|
||||
<p>To get this object from the cluster, we use <a href="2">Kubernetes Informers</a>, in particular, <code class="codehilite">FilteredSharedInformer</code>. This informers allows reacting to changes in using <a href="3">callbacks</a> to individual changes when a new object is added, modified or removed. Unfortunately, there is no way to know if a particular change is going to affect the final configuration file. Therefore on every change, we have to rebuild a new model from scratch based on the state of cluster and compare it to the current model. If the new model equals to the current one, then we avoid generating a new NGINX configuration and triggering a reload. Otherwise, we check if the difference is only about Endpoints. If so we then send the new list of Endpoints to a Lua handler running inside Nginx using HTTP POST request and again avoid generating a new NGINX configuration and triggering a reload. If the difference between running and new model is about more than just Endpoints we create a new NGINX configuration based on the new model, replace the current model and trigger a reload.</p>
|
||||
<p>Usually, a Kubernetes Controller utilizes the <a href="https://coreos.com/kubernetes/docs/latest/replication-controller.html#the-reconciliation-loop-in-detail">synchronization loop pattern</a> to check if the desired state in the controller is updated or a change is required. To this purpose, we need to build a model using different objects from the cluster, in particular (in no special order) Ingresses, Services, Endpoints, Secrets, and Configmaps to generate a point in time configuration file that reflects the state of the cluster.</p>
|
||||
<p>To get this object from the cluster, we use <a href="https://godoc.org/k8s.io/client-go/informers#NewFilteredSharedInformerFactory">Kubernetes Informers</a>, in particular, <code class="codehilite">FilteredSharedInformer</code>. This informers allows reacting to changes in using <a href="https://godoc.org/k8s.io/client-go/tools/cache#ResourceEventHandlerFuncs">callbacks</a> to individual changes when a new object is added, modified or removed. Unfortunately, there is no way to know if a particular change is going to affect the final configuration file. Therefore on every change, we have to rebuild a new model from scratch based on the state of cluster and compare it to the current model. If the new model equals to the current one, then we avoid generating a new NGINX configuration and triggering a reload. Otherwise, we check if the difference is only about Endpoints. If so we then send the new list of Endpoints to a Lua handler running inside Nginx using HTTP POST request and again avoid generating a new NGINX configuration and triggering a reload. If the difference between running and new model is about more than just Endpoints we create a new NGINX configuration based on the new model, replace the current model and trigger a reload.</p>
|
||||
<p>One of the uses of the model is to avoid unnecessary reloads when there's no change in the state and to detect conflicts in definitions.</p>
|
||||
<p>The final representation of the NGINX configuration is generated from a <a href="6">Go template</a> using the new model as input for the variables required by the template.</p>
|
||||
<p>The final representation of the NGINX configuration is generated from a <a href="https://github.com/kubernetes/ingress-nginx/blob/master/rootfs/etc/nginx/template/nginx.tmpl">Go template</a> using the new model as input for the variables required by the template.</p>
|
||||
<h2 id="building-the-nginx-model">Building the NGINX model<a class="headerlink" href="#building-the-nginx-model" title="Permanent link">¶</a></h2>
|
||||
<p>Building a model is an expensive operation, for this reason, the use of the synchronization loop is a must. By using a <a href="4">work queue</a> it is possible to not lose changes and remove the use of <a href="5">sync.Mutex</a> to force a single execution of the sync loop and additionally it is possible to create a time window between the start and end of the sync loop that allows us to discard unnecessary updates. It is important to understand that any change in the cluster could generate events that the informer will send to the controller and one of the reasons for the <a href="4">work queue</a>.</p>
|
||||
<p>Building a model is an expensive operation, for this reason, the use of the synchronization loop is a must. By using a <a href="https://github.com/kubernetes/ingress-nginx/blob/master/internal/task/queue.go#L38">work queue</a> it is possible to not lose changes and remove the use of <a href="https://golang.org/pkg/sync/#Mutex">sync.Mutex</a> to force a single execution of the sync loop and additionally it is possible to create a time window between the start and end of the sync loop that allows us to discard unnecessary updates. It is important to understand that any change in the cluster could generate events that the informer will send to the controller and one of the reasons for the <a href="https://github.com/kubernetes/ingress-nginx/blob/master/internal/task/queue.go#L38">work queue</a>.</p>
|
||||
<p>Operations to build the model:</p>
|
||||
<ul>
|
||||
<li>Order Ingress rules by <code class="codehilite">ResourceVersion</code> field, i.e., old rules first.</li>
|
||||
<li>If the same path for the same host is defined in more than one Ingress, the oldest rule wins.</li>
|
||||
<li>
|
||||
<p>Order Ingress rules by <code class="codehilite">ResourceVersion</code> field, i.e., old rules first.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If the same path for the same host is defined in more than one Ingress, the oldest rule wins.</p>
|
||||
</li>
|
||||
<li>If more than one Ingress contains a TLS section for the same host, the oldest rule wins.</li>
|
||||
<li>
|
||||
<p>If multiple Ingresses define an annotation that affects the configuration of the Server block, the oldest rule wins.</p>
|
||||
|
|
88
sitemap.xml
88
sitemap.xml
|
@ -2,222 +2,222 @@
|
|||
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
<url>
|
||||
<loc>None</loc>
|
||||
<lastmod>2018-11-02</lastmod>
|
||||
<lastmod>2018-11-05</lastmod>
|
||||
<changefreq>daily</changefreq>
|
||||
</url>
|
||||
</urlset>
|
BIN
sitemap.xml.gz
BIN
sitemap.xml.gz
Binary file not shown.
Loading…
Reference in a new issue