k8s-ingress | Kubernetes Ingress Controller based on Varnish NOTE : WORK | Load Balancing library

by uplex/varnish Go Version: 0.1.0-ALPHA License: Non-SPDX

X-Ray Key Features Code Snippets(1)Community Discussions(7)Vulnerabilities Install Support

kandi X-RAY | k8s-ingress Summary

k8s-ingress is a Go library typically used in Networking, Load Balancing applications. k8s-ingress has no bugs, it has no vulnerabilities and it has low support. However k8s-ingress has a Non-SPDX License. You can download it from GitLab.

This is an implementation of a Kubernetes Ingress controller based on Varnish, with haproxy for TLS termination.

Support

Quality

Security

License

Reuse

Support

k8s-ingress has a low active ecosystem.

It has 7 star(s) with 3 fork(s). There are no watchers for this library.

It had no major release in the last 12 months.

There are 17 open issues and 0 have been closed. On average issues are closed in 158 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of k8s-ingress is 0.1.0-ALPHA

Quality

k8s-ingress has no bugs reported.

Security

k8s-ingress has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

License

k8s-ingress has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

k8s-ingress releases are available to install and integrate.

Installation instructions, examples and code snippets are available.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of k8s-ingress

Get all kandi verified functions for this library.

k8s-ingress Key Features

No Key Features are available at this moment for k8s-ingress.

k8s-ingress Examples and Code Snippets

Installation

Lines of Code : 5

License : Non-SPDX

Copy

kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: "varnish"
[...]

Community Discussions

Trending Discussions on k8s-ingress

Kubernetes - Ingress - caught by a more general rule

Istio authorization policy not applying on child gateway

Terraform Removes Configurations/Resources Created by the Application Gateway Ingress Controller (AGIC)

Kubernetes Nginx Ingress can connect to https pods?

Load balancing in front of Traefik edge router

Istio: Can not access service with gateway over HTTP/HTTPS

Nginx Fails with my variables in location

QUESTION

Kubernetes - Ingress - caught by a more general rule

Asked 2021-May-17 at 14:29

I'm trying to set up an Ingress rule for a service (Kibana) running in my microk8s cluster but I'm having some problems.

The first rule set up is

...

ANSWER

Answered 2021-May-17 at 14:27

Add the following annotation to the kibana ingress so that nginx-ingress interprets the /kibana(/|$)(.*) path using regex:

Source https://stackoverflow.com/questions/67570303

QUESTION

Istio authorization policy not applying on child gateway

Asked 2020-Sep-09 at 05:14

What I am trying to achieve: block all traffic to a service, containing the code to handle this within the same namespace as the service.

Why: this is the first step in "locking down" a specific service to specific IPs/CIDRs

I have a primary ingress GW called istio-ingressgateway which works for services.

...

ANSWER

Answered 2020-Sep-01 at 06:52

As far as I know you should rather use AuthorizationPolicy in 3 ways

on ingress gateway
on namespace
on specific service

I have tried to make it work on a specific gateway with annotations like you did, but I couldn't make it work for me.

e.g.

the following authorization policy denies all requests to workloads in namespace x.

Source https://stackoverflow.com/questions/63647973

QUESTION

Terraform Removes Configurations/Resources Created by the Application Gateway Ingress Controller (AGIC)

Asked 2020-Sep-01 at 18:02

I have some Terraform code which deploys AKS behind an Application Gateway along with other infrastructure unrelated to the issue. The code is based on https://docs.microsoft.com/en-us/azure/developer/terraform/create-k8s-cluster-with-aks-applicationgateway-ingress. I can provide the actual files if needed.

All the infrastructure is being deployed successfully on initial creation, however when I configure the AGIC pods and deploy an application such as Nginx, it creates resources such as routing rules on the Application Gateway that is unknown to Terraform so if I run a Terraform deployment, it will revert back to what is in code (regardless if I made any changes or not). This causes the routing to my application through the ingress controller to return a 502 until it is redeployed.

How can I work around this?

...

ANSWER

Answered 2020-Sep-01 at 18:02

Not the approach I want, but looks like the one I will need. Basically you can configure Terraform to ignore_changes which will create all resources but ignore modifications. You can define the resources to ignore as well as you can see below:

Source https://stackoverflow.com/questions/63691139

QUESTION

Kubernetes Nginx Ingress can connect to https pods?

Asked 2020-Apr-23 at 08:55

I have three pods with HTTPS servers inside. I used to acces them via NodePort services. Now I deployed a Nginx Ingress to have them all in one IP. I have noticed that the Nginx Ingress can't connect with an HTTPS server in a pod, but it connects perfectly if I change it to HTTP.

How can I make the Ingress connect with HTTPS servers in pods?

I have tried to configure a tls secret, and add it to the Ingress:

...

ANSWER

Answered 2020-Apr-23 at 08:55

From the docs here you need to add this annotation

Source https://stackoverflow.com/questions/61382853

QUESTION

Load balancing in front of Traefik edge router

Asked 2020-Feb-03 at 18:28

Looking at OpenShift HA proxy or Traefik project: https://docs.traefik.io/. I can see Traefik ingress controller is deployed as a DaemonSet. It enables to route traffic to correct services/endpoints using virtual host.

Assuming I have a Kubernetes cluster with several nodes. How can I avoid to have a single point of failure?

Should I have a load balancer (or DNS load balancing), in front of my nodes?

If yes, does it mean that:

Load balancer will send traffic to one node of k8s cluster
Traefik will send the request to one of the endpoint/pods. Where this pod could be located in a different k8s node?

Does it mean there would be a level of indirection?

I am also wondering if the F5 cluster mode feature could avoid such indirection?

EDIT: when used with F5 Ingress resource

...

ANSWER

Answered 2020-Feb-03 at 15:20

You can have a load balancer (BIG IP from F5 or a software load balancer) for traefik pods. When client request comes in it will sent to one of the traefik pods by the load balancer. Once request is in the traefik pod traefik will send the request to IPs of the kubernetes workload pods based on ingress rules by getting the IPs of those pods from kubernetes endpoint API.You can configure L7 load balancing in traefik for your workload pods.

Using a software reverse proxy such as nginx and exposing it via a load balancer introduces an extra network hop from the load balancer to the nginx ingress pod.

Looking at the F5 docs BIG IP controller can also be used as ingress controller and I think using it that way you can avoid the extra hop.

Source https://stackoverflow.com/questions/60031377

QUESTION

Istio: Can not access service with gateway over HTTP/HTTPS

Asked 2019-Nov-22 at 13:21

Istio: 1.3 (also tried 1.1 before update to 1.3)
K8s: 1.16.2
Cloud provider: DigitalOcean

I have a cluster setup with Istio. I have enabled grafana/kiali and also installed kibana and RabbitMQ management UI and for all of those I have gateways and virtual services configured (all in istio-system namespace) along with HTTPS using SDS and cert-manager and all works fine. It means I can access these resources in the browser over HTTPS with a sub domain.

Then I deployed a microservice (part of a real application) and created Service, VirtualService and Gateway resources for it (for now it is the only one service and gateway except rabbitmq which uses different sub domain and differend port). And it is located in default namespace.

...

ANSWER

Answered 2019-Nov-22 at 13:21

Issue was really simple and silly. I had enabled global.k8sIngress.enabled = true in Istio values.yml. After changing it to false all starts working.

Source https://stackoverflow.com/questions/58820013

QUESTION

Nginx Fails with my variables in location

Asked 2019-Feb-07 at 19:29

So I am trying to set up an nginx default.conf and I'm having trouble using variables. I want to capture the subdomain as the $subdomain variable and use it a few times in the default.conf.

Here is my config:

...

ANSWER

Answered 2019-Feb-07 at 18:07

According to the manual page:

When variables are used in proxy_pass: ... In this case, if URI is specified in the directive, it is passed to the server as is, replacing the original request URI.

So you need to construct the complete URI for the upstream server.

For example:

Source https://stackoverflow.com/questions/54563363

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install k8s-ingress

Varnish and haproxy for the purposes of Ingress run together in a Pod, and the controller that manages them runs in a separate Pod -- one controller can be used to manage a group of Pods implementing Ingress. The Dockerfiles and other files needed to build the three images are in the container/ folder, together with a Makefile that encapsulates the commands for the build. The resulting images must then be pushed to a registry available to the Kubernetes cluster. The Ingress can then be deployed by any of the means that are customary for Kubernetes. The deploy/ folder contains manifests (YAMLs) for some of the ways to deploy an Ingress, using tools such as kubectl. The charts/ folder contains charts for Helm deployments. The deployment described in deploy/ targets a default setup in which the controller runs in the kube-system namespace and watches in all namespaces of the cluster for Ingresses, Services and so on that are intended for the Varnish implementation. See the instructions for single-namespace deployments if you need to limit the deployment to one namespace. The examples/ folder contains YAMLs for Services and Ingresses to test and demonstrate the Varnish implementation and its features. You might want to begin with the "cafe" example inspired by other projects (a kind of "hello world" for Ingress).