Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Ingress resource #14

Open
holoGDM opened this Issue Jun 28, 2017 · 33 comments

Comments

Projects
None yet
@holoGDM
Copy link

commented Jun 28, 2017

Hello

There is lack of ingress resources support in Terraform. Please can you add it?

Regards
holoGDM

@radeksimko

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2017

Hi @holoGDM
unfortunately ingress is currently in v1beta phase: https://kubernetes.io/docs/resources-reference/v1.6/#ingress-v1beta1-extensions

As mentioned in the Readme, for reasons discussed in #1 (comment) there are currently no plans on supporting any API that's marked as alpha, beta or generally anything that's not stable/v1.

Thanks for understanding.

@sl1pm4t

This comment has been minimized.

Copy link
Contributor

commented Oct 26, 2017

Hi @holoGDM - I've just added support for the Ingress resource over in my fork:
https://github.com/sl1pm4t/terraform-provider-kubernetes/releases/tag/v1.0.2-custom

See example usage here:
https://github.com/sl1pm4t/terraform-provider-kubernetes/tree/custom/_examples/ingress

Obviously use with caution because this is not official and has no guarantees for backwards compatibility going forward.

@aeneasr

This comment has been minimized.

Copy link

commented Nov 9, 2017

Since this isn't currently possible, how would I go about adding an HTTPS proxy in front of the LoadBalancer using the GCP provider?

As far as I understand, type="LoadBalancer" creates a GCP Backend Service with a frontend that listens on randomly assigned IP Address (frontend) and the a (virtual?) instance group pointing to GKE (backend). That works nicely, however, it's not possible to link a GCP HTTPS Proxy with that IP address assigned to the frontend, as I'm only able to connect that proxy with a GCP Backend Service, which requires an instance group. Since there isn't a way to query for that created backend (load_balancer_ingress only gives the IP address) it's basically impossible to do this.

I would appreciate any help/pointers/RTFM regarding that as I'm stuck.

ddub pushed a commit to ddub/terraform-provider-kubernetes that referenced this issue Jun 21, 2018

Merge pull request terraform-providers#14 from sl1pm4t/fix-statefulse…
…t-update-strategy

Fix StatefulSet update strategy
@tsirlucas

This comment has been minimized.

Copy link

commented Jul 12, 2018

Any updates on this one? I'm going through the same problem.

@arekkas Did you find a workaround for your problem?

@iorlas

This comment has been minimized.

Copy link

commented Nov 2, 2018

Same here, waiting, crying

@aeneasr

This comment has been minimized.

Copy link

commented Nov 2, 2018

I gave up on it and just added HTTPS to my service.

@aeneasr

This comment has been minimized.

@Radik2

This comment has been minimized.

Copy link

commented Dec 5, 2018

Hello all,
Any updates on this one? I have same problem but with OpenStack :( .Are there any plans to add Ingress resource soon ?

@Radik2

This comment has been minimized.

Copy link

commented Dec 6, 2018

Hello @sl1pm4t ,

Has this https://github.com/sl1pm4t/terraform-provider-kubernetes/blob/custom/_examples/ingress/main.tf ever worked or it work only with v1beta ? I have Terraform v0.11.10 with provider.kubernetes v1.3.0.
When I run "kubernetes_ingress" part of the code it says : "Provider doesn't support resource: kubernetes_ingress"

@zero-below

This comment has been minimized.

Copy link

commented Dec 6, 2018

@Radik2,

The blurb you referenced works with a provider built from sl1pm14t's provider fork, not the official fork.

As a side note, I see up above in comments in this thread, people trying to get ssl to work. Here's how to do it.

    annotations {
      "ingress.gcp.kubernetes.io/pre-shared-cert" = "${ var.ssl_cert_name }"
      "kubernetes.io/ingress.allow-http" = "false"
      "kubernetes.io/ingress.global-static-ip-name" = "${ google_compute_global_address.lb-address.name }"
    }
@acobaugh

This comment has been minimized.

Copy link

commented Dec 7, 2018

I normally voice support for an issue with a thumbs up to avoid spam, but this is getting somewhat ridiculous. Any ETA on when ingress will be supported? I've been using @sl1pm4t's fork with great success, but the setup to use that provider instead of simply being able to do terraform init is quite cumbersome when on a team...

I really want to use terraform to manage kubernetes, as I and others believe it is far superior to helm charts (templating out structured text?) or writing out endless yaml files. However, lack of support for even Stable features is a potential show-stopper for us.

@sarneaud

This comment has been minimized.

Copy link

commented Dec 7, 2018

However, lack of support for even Stable features is a potential show-stopper for us.

The Ingress resource is still in beta:
https://kubernetes.io/docs/concepts/services-networking/ingress/#prerequisites

@aeneasr

This comment has been minimized.

Copy link

commented Dec 8, 2018

I agree with @acobaugh 's sentiment. And by the way, the Google Provider is exposing a beta provider which leaves it to the implementer's discretion as to whether use it or not. I agree that simple use cases as setting up SSL for inbound traffic (via Ingress), which is supported on major platforms for over a year (years?) really puts a limit to the usefulness of the k8s provider, significantly increases developer frustration (as seen on this thread) and doesn't make a lot of sense as we're seeing other providers supporting beta features. On top of that, the community is apparently willing to provide enhancements and code changes that support these features, but it's really up to the maintainers to finally take the necessary step.

LETS FINALLY DO SOMETHING ABOUT IT

@cupojoe

This comment has been minimized.

Copy link

commented Jan 13, 2019

I'm not sure what the deterrent to implementing Google's beta API is. Google is famous for leaving very stable products in beta for years.
I think implementing something like @sl1pm4t solution and flagging/warning the docs with a beta status would be sufficient to make the community happy and the k8 provider much more useful.
To get around this I've been using a sh script to create the ingress, but it's ugly to say the least.
Would love to hear from the maintainers why such a hard stance on the beta status from Google.
This is my ingress script in case it helps someone:

## Get creds from the cluster. This can be done by passing a KUBECONFIG env variable instead, setting it in terraform
echo "Updating cluster credentials"
gcloud container clusters get-credentials $CLUSTER_NAME --zone $ZONE
echo "Creating ingress resource"
# Dynamically replace the name of the static ip resource in the yaml file
INGRESS_YAML=`cat "ingress/ingress.yaml" | sed "s/{{IP_NAME}}/$STATIC_IP_NAME/g" | sed "s/{{INGRESS_NAME}}/$INGRESS_NAME/g"`
echo "$INGRESS_YAML" | kubectl apply -f -
external_ip=$(kubectl get ingress my-ingress-name --template="{{range .status.loadBalancer.ingress}}{{.ip}}{{end}}")
time_spent=0
time_out=300
while [ -z "$external_ip" ] && [ "$time_spent" -lt "$time_out" ]; do
    external_ip=$(kubectl get ingress my-ingress-name --template="{{range .status.loadBalancer.ingress}}{{.ip}}{{end}}")
    time_spent=$(($time_spent+5))
    sleep 5
done

if [ -z "$external_ip" ]
then
    echo "Time out. Unable to create ingress. Try running terraform apply again."
    exit 1
else
    echo "Load balancer ready at: $external_ip"
fi

I call this from a null local exec resource like this:

resource "null_resource" "my-ingress" {
  # Required so this triggers every time. It won't affect the ingress if nothing has changed
  triggers {
    key = "${uuid()}"
  }
  provisioner "local-exec" {
    command = ". ingress/create-ingress.sh"
    environment {
      SERVICE_NAME = "${var.service_name}"
      CLUSTER_NAME = "${var.cluster_name}"
      STATIC_IP_NAME = "${var.static_ip_name}"
      INGRESS_NAME = "${var.ingress_name}"
      ZONE = "${var.zone}"
      REGION = "${var.region}"
    }
  }
}
@Radik2

This comment has been minimized.

Copy link

commented Jan 22, 2019

Hello again guys :) , Hello @sl1pm4t ,

Is there "secretName" as a rule in or something else we can set in fork Ingress resource ? I have tried to set "secretName" , "secret_name" or "secretname" but Terraform Fork does know about that...Like this for example

rule {
host = "myminikube.info"
secret_name = "name_of_secret" --> "invalid or unknown key: secret_name"

  http {
    path {
      path_regex = "/"

      backend {
        service_name = "echoserver"
        service_port = 8080
      }
    }
  }

}

My idea is to secure the Ingress resource ...Is there any other way to secure it ?
Any help will be appreciated :)

@Radik2

This comment has been minimized.

Copy link

commented Jan 25, 2019

Hello :) ,

Could somebody help me ?I think it does not make sense to create ingress if it is not secured...
Thank you!

@sl1pm4t

This comment has been minimized.

Copy link
Contributor

commented Jan 29, 2019

Hi @Radik2
The secret_name attribute needs to be nested instead a tls block like:

...
  spec {
    tls {
      secret_name = "tls-secret"
    }
...
@Radik2

This comment has been minimized.

Copy link

commented Jan 30, 2019

Hello @sl1pm4t and thank you very much for your answer . It works but something else is worrying me :
I set following structure
spec {
tls {
hosts = "example.com"

  secret_name = "tls-secret"
}

}

And terraform said "hosts: should be a list" and then I set to :

spec {
tls {
hosts = ["example.com"]

  secret_name = "tls-secret"
}

}

Which was accepted as syntax but in Kubernetes UI in Ingress yaml file I see following configuration uploaded:

"hosts": [
"example.com"
],
And those "[" brackets I think should not be there...? Might be I do not understand something...

@Radik2

This comment has been minimized.

Copy link

commented Jan 31, 2019

Hello @sl1pm4t and thank you very much for your answer . It works but something else is worrying me :
I set following structure
spec {
tls {
hosts = "example.com"

  secret_name = "tls-secret"
}

}

And terraform said "hosts: should be a list" and then I set to :

spec {
tls {
hosts = ["example.com"]

  secret_name = "tls-secret"
}

}

Which was accepted as syntax but in Kubernetes UI in Ingress yaml file I see following configuration uploaded:

"hosts": [
"example.com"
],
And those "[" brackets I think should not be there...? Might be I do not understand something...

Please ignore above message . I have tested with kubectl and yaml. file and it work like that so no worries

@bcornils bcornils modified the milestones: Research, v1.7.0 Feb 7, 2019

@Radik2

This comment has been minimized.

Copy link

commented Feb 8, 2019

Hello guys,

Let me ask you if you have ever had a problem with the "tfstate" file while initializing the backend which in my case is Nexus or Artifactory :
Initializing the backend...

Successfully configured the backend "artifactory"! Terraform will automatically
use this backend unless the backend configuration changes.
Error refreshing state: Get hostNameOfRemoteArtifactory: dial tcp someipaddress:port: getsockopt: no route to host

I have tested with official release for Kubernetes here https://www.terraform.io/docs/providers/kubernetes/guides/getting-started.html and it works :)

Thank you in advance

@tdmalone

This comment has been minimized.

Copy link

commented Feb 22, 2019

Hi @Radik2, this issue is about a feature request for the Ingress resource. You'd be best posting a new issue to request help on something unreleated to this issue :)

@tburow

This comment has been minimized.

Copy link

commented Feb 27, 2019

Updates on this feature request? seems this is somewhat a core feature that should be added. with out it, I'm finding this provider useless like getting to the 1 yard line and going home..

@tburow

This comment has been minimized.

Copy link

commented Feb 27, 2019

Here is an example for a workaround, but still would like this resolved. I hope this snippet helps others.

data "template_file" "ingress" {
  template = "${file("templates/ingress.yaml.tpl")}"
  vars {
    INGRESS_NAME = "<value>"
    HOSTNAME     ="<value>"
    PATH         = "<value>"
    SERVICENAME  = "<value>"
    SERVICEPORT  = "<value>"
  }
}
resource "null_resource" "ingress" {
  triggers = {
    manifest_sha1 = "${sha1("${data.template_file.ingress.rendered}")}"
  }

  provisioner "local-exec" {
    command = "kubectl apply -f -<<EOF\n${data.template_file.ingress.rendered}\nEOF"
  }
}
ingress.yaml.tpl
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ${INGRESS_NAME}
spec:
  rules:
  - host: ${HOSTNAME}
    http:
      paths:
      - path: ${PATH}
        backend:
          serviceName: ${SERVICENAME}
          servicePort: ${SERVICEPORT}

@roidelapluie

This comment has been minimized.

Copy link

commented Mar 2, 2019

I agree that ingress is ridiculously missing in this provider

@tburow

This comment has been minimized.

Copy link

commented Mar 14, 2019

bump - Im pushing on both repos/project to resolve this. seems easy enough since the code was already written and in a PR.

@eveenendaal

This comment has been minimized.

Copy link

commented Mar 14, 2019

Maybe the feature could be added to a kubernetes-beta provider like the google-beta provider? https://www.terraform.io/docs/providers/google/provider_versions.html

@Korijn

This comment has been minimized.

Copy link

commented Mar 27, 2019

Is there any expected date for promotion of Ingress to stable API?

@tburow

This comment has been minimized.

Copy link

commented Mar 27, 2019

kubernetes/kubernetes#74679

Pressing them as much as I can for information/schedule

@aeneasr

This comment has been minimized.

Copy link

commented Mar 27, 2019

I think that's the wrong approach. Upstream shouldn't force a GA release just because this provider doesn't want to implement beta features. Doing what @eveenendaal suggested is way smarter IMO.

@Korijn

This comment has been minimized.

Copy link

commented Mar 27, 2019

I'm not interested in pressuring/forcing anything, I intend to wait for this stuff to become stable. I was just wondering if there is any public timeline/roadmap available.

@alexsomesan

This comment has been minimized.

Copy link
Contributor

commented Mar 27, 2019

Hi all. All the demand for this hasn't gone unnoticed. I will try to work on the Ingress resource in the next few days.

@tburow

This comment has been minimized.

Copy link

commented Mar 27, 2019

IMHO the fact that this has been in this state on K8S for "years" seems to be an issue. I am only pursuing getting the issue some attention as its a limiting factor for the K8S community not just this provider. Trying to find some common ground. if there is a real reason ingress was never rolled to GA then so be it, but it seems to be in the current state due to lack of attention, not technical reasoning.

@tburow

This comment has been minimized.

Copy link

commented Mar 28, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.