ingress-gce | Ingress controller for Google Cloud | GCP library

by kubernetes Go Version: v1.8.0 License: Apache-2.0

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

kandi X-RAY | ingress-gce Summary

ingress-gce is a Go library typically used in Cloud, GCP applications. ingress-gce has no bugs, it has no vulnerabilities, it has a Permissive License and it has medium support. You can download it from GitHub.

See here for high-level concepts on Ingress in Kubernetes. For GCP-specific documentation, please visit here (core use-cases) and here (other cool features).

Support

Quality

Security

License

Reuse

Support

ingress-gce has a medium active ecosystem.

It has 1216 star(s) with 301 fork(s). There are 69 watchers for this library.

It had no major release in the last 12 months.

There are 31 open issues and 397 have been closed. On average issues are closed in 373 days. There are 19 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of ingress-gce is v1.8.0

Quality

ingress-gce has no bugs reported.

Security

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

License

ingress-gce is licensed under the Apache-2.0 License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

ingress-gce releases are available to install and integrate.

Installation instructions are not available. 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 ingress-gce

Get all kandi verified functions for this library.

ingress-gce Key Features

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

ingress-gce Examples and Code Snippets

No Code Snippets are available at this moment for ingress-gce.

Community Discussions

Trending Discussions on ingress-gce

Implementing workaround for missing http->https redirection in ingress-gce with GLBC

How to get a custom healthcheck path in a GCE L7 balancer serving a Kubernetes Ingress?

GKE Ingress is slow to pick up pod readiness/liveness

Apache reverse proxy in front of an ingress-gce (GKE)

Google Endpoints + GKE + GRPC

QUESTION

Implementing workaround for missing http->https redirection in ingress-gce with GLBC

Asked 2020-May-24 at 05:01

I am trying to wrap my brain around the suggested workarounds for the lack of built-in HTTP->HTTPS redirection in ingress-gce, using GLBC. What I am struggling with is how to use this custom backend that is suggested as one option to overcome this limitation (e.g. in How to force SSL for Kubernetes Ingress on GKE).

In my case the application behind the load-balancer does not itself have apache or nginx, and I just can't figure out how to include e.g. apache (which I know way better than nginx) in the setup. Am I supposed to set apache in front of the application as a proxy? In that case I wonder what to put in the proxy config as one can't use those convenient k8s service names there...

Or should apache be set up as some kind of a separate backend, which would only get traffic when the client uses plain HTTP? In that case I am missing the separation of backends by protocol in the GCE load-balancer, and while I can see how that could be done manually, the ingress needs to be configured for that, and I can't seem to find any resources explaining how to actually do that.

For example, in https://github.com/kubernetes/ingress-gce#redirecting-http-to-https the "application" takes care of the forwaring (it seems to be built on nginx), and while that example works beautifully, it's not possible to do the same thing with the application I am talking about.

Basically, my setup is currently this:

...

ANSWER

Answered 2020-May-24 at 05:01

Edit in May 2020: "HTTP(S) Load Balancing Rewrites and Redirects support is now in General Availability" as stated in https://issuetracker.google.com/issues/35904733#comment95 seems to mean that now it finally would be possible to implement proper rediction rules in the LB itself, without having to resort to having an extra pod or any other tweak of that kind. However, in case the below is of use to someone, I'll leave it there for reference.

I was able to find a solution, where the GCE LB directs traffic to Apache (of course this should work for any proxy) which runs as a deployment in K8s cluster. In Apache config, there's a redirect based on X-Forwarded-Proto header, and a reverse proxy rules that point to the application in the cluster.

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

QUESTION

How to get a custom healthcheck path in a GCE L7 balancer serving a Kubernetes Ingress?

Asked 2020-Apr-16 at 11:06

I'm trying to deploy a grafana instance inside Kubernetes (server 1.6.4) in GCE. I'm using the following manifests:

Deployment (full version):

...

ANSWER

Answered 2017-Jun-20 at 23:55

Customizing Health Checks With GLBC addon

It is not quite clear from your question, but if you're using the GCE Load-Balancer Controller (GLBC) Cluster Addon, you can customize the health check path.

Currently, all service backends must satisfy either of the following requirements to pass the HTTP(S) health checks sent to it from the GCE loadbalancer:

Respond with a 200 on '/'. The content does not matter.

Expose an arbitrary url as a readiness probe on the pods backing the Service.

The Ingress controller looks for a compatible readiness probe first, if it finds one, it adopts it as the GCE loadbalancer's HTTP(S) health check. If there's no readiness probe, or the readiness probe requires special HTTP headers, the Ingress controller points the GCE loadbalancer's HTTP health check at '/'. This is an example of an Ingress that adopts the readiness probe from the endpoints as its health check.

The GLBC addon page mentions this in the Limitations section:

All Kubernetes services must serve a 200 page on '/', or whatever custom value you've specified through GLBC's --health-check-path argument.

Without GLBC addon

If you're not using the addon, currently Kubernetes does require you to serve 200 for GET requests on / path for successful health checks otherwise the backend will not get any traffic.

There is a bit of background about this in this bug.

Google Container Engine (GKE)

If you're on Google Container Engine (GKE), the same default Kubernetes requirements for health checks apply there too.

Services exposed through an Ingress must serve a response with HTTP 200 status to the GET requests on / path. This is used for health checking. If your application does not serve HTTP 200 on /, the backend will be marked unhealthy and will not get traffic.

Answer to your real issue

Having said all of this, as you (@mmoya) point out in your answer, adding the same port that is used for readiness probe as one of the ports in the pod fixes the issue for your case since the port itself is not exposed outside the pod otherwise. This caused Kubernetes to rely on the health check from / instead.

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

QUESTION

GKE Ingress is slow to pick up pod readiness/liveness

Asked 2019-Dec-17 at 16:47

I managed to create a cluster using GKE using gce ingress successfully. However it takes a long time for Ingress to detect the service is ready (I already set both livenessProbe and readinessProbe). My pods set up

...

ANSWER

Answered 2019-Dec-17 at 13:01

When using GCE Ingress, you need to wait for the load balancer provisioning time before the backend service is deemed as healthy.

Consider that when you use this ingress class, you're relying on the GCE infrastructure that automatically has to provision an HTTP(S) load balancer and all of its components before sending requests into the cluster.

When you set up a deployment without readinessProbe, the default values are going to be applied to the load balancer health check:

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

QUESTION

Apache reverse proxy in front of an ingress-gce (GKE)

Asked 2019-May-23 at 00:05

I´m trying to overcome the ingress-gce limitation of redirect traffic from HTTP to HTTPS.

So, the easiest configuration whould be a Reverse Proxy with Apache2 but isn't working for me, this apache is in another VM apart from my kubernetes cluster, I just want to "proxy" the traffic so I can manipulate the request, redirect to https, etc

I´m need this specific solution to work as I can´t configure a nginx ingress at this point, it has to be done with this GCE ingress

My ingress yaml configuration is:

...

ANSWER

Answered 2019-May-23 at 00:05

The ingress controller doesn't have a handler for myother.domain.com so produces a 404.

You either need to setup an additional Ingress host for myother.domain.com or turn ProxyPreserveHost Off so the proxy sends the mycustom.domain.com host name from the ProxyPass config.

How the tomcat application make use of the Host header is usually the decider for which way you need to map the header through the proxy.

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

QUESTION

Google Endpoints + GKE + GRPC

Asked 2019-Jan-15 at 13:54

I've been trying to deploy a grpc application to be frontend by google endpoints on a GKE cluster and terminating TLS on the load balancer itself for the better part of 3 days now and I am very confused how to get this working.

At first I tried a simple deployment without Google endpoints to make sure the load balancer works. It is described in more detail here

https://github.com/kubernetes/ingress-gce/issues/18#issuecomment-454047010

That did not work. I then followed up by trying to deploy the application here

https://github.com/salrashid123/gcegrpc/tree/master/gke_ingress_lb

That seems to have worked well however I am not quite able to understand what makes it work. It seems to me (as suggested by someone else) that it might be because the application speaks TLS on the grpc endpoint

I have tried enabling TLS in my application grpc endpoint including adding a grpc health check as suggested by someone else however that did not seem to help.

My esp config was something as simple as

...

ANSWER

Answered 2019-Jan-15 at 13:54

Figured out how to do it. Turns out there are a couple, not so well documented, things that need to be done.

See here for the details

https://github.com/GoogleCloudPlatform/endpoints-samples/issues/52#issuecomment-454387373

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

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