koli / kong-ingress Goto Github PK

followed steps what ever specified in docs and domains, kong wit postgres running. and exposed kong deployment as proxy on 8000, added apps (web and hello) with ingress. but, not able to connect web/hello apps.

trying this "http://acme.local:8000" outside and getting "This site can’t be reached" and even no logs observed in ingress and kong (/usr/local/kong/logs/) pods. What could be the issue? how to debug this issues.

The community edition of kong version 0.13 was recently released.

• https://konghq.com/blog/kong-ce-0-13-0-released/
• https://github.com/Kong/kong/releases/tag/0.13.0

This release includes Services and Routes core entities as well as the deprecation of the API entity.

What are the plans / timeline for supporting the new version?

The ingress deals with new routes providing only the required fields. To change an API configuration of a route it's a manual process.
The Pull Request #24 introduces a way of configuring the strip_uri attribute using an ingress annotation.

Instead of specifying an annotation for each ingress resource, I propose a global configuration for defining default values for API routes, and annotations could be used to override those defaults.

E.g.:

Binary args

# In this example each route will be provisioned with those values
./kong-ingress --strip-uri=false --preserve-host=true --retries=10

Or environment variable configuration

STRIP_URI=false
PRESERVE_HOST=true

Reference: https://getkong.org/docs/0.11.x/admin-api/#add-api

I can see that kong seemingly supports http-2, but kong-ingress may be behind.
Certainly my attempt at a grpc connection yields:
error => { Error: Trying to connect an http1.x server

Would that be a known issue?

while kube-ingress deploy, throwing below error:
F1130 22:55:42.706514 1 main.go:139] failed creating domains TPR: thirdpartyresources.extensions is forbidden: User "system:serviceaccount:kong-system:default" cannot create thirdpartyresources.extensions at the cluster scope

k8s V1.8, thirdpartyresources.extensions are removed @ https://kubernetes.io/docs/tasks/access-kubernetes-api/extend-api-third-party-resource/

A new API object type called a Custom Resource Definition (CRD) will replace the existing Third Party Resource (TPR) extension mechanism over the next Kubernetes releases.

This issue is to track the transition between TPR to CRD

is there a known problem/limitation with it?

We should check supported images using regular expression. There are situations where we want to use -alpha -beta or -rcX images.

F0823 15:49:33.844585       1 main.go:123] failed retrieving kong version: failed converting version: strconv.Atoi: parsing "0rc2": invalid syntax

It should normalize the path instead of doing nothing

Dep it's mature enough to deal with vendoring for this project

So, I register a new route, and re-deploy kong-ingress, API got registered, and my MS that gets traffic from that route, works.
If that MS has some issue or stops working, API will get unregistered, but when it gets resolved (or we re-deploy that MS), kong-ingress will not re-register that API, therefor our MS will not work. We end up re-deploying kong-ingress, which get this API registered again and MS working again.

This is what I found on kong-ingress pod:
I0416 14:11:24.398947 1 utils.go:90] Syncing ms/MSNAME
I0416 14:11:24.399137 1 controller.go:189] ms/MSNAME - gc=true, service resource doesn't exists
I0416 14:27:22.775073 1 utils.go:90] Syncing ms/MSNAME

Am I missing something? Is there a proper way of doing this?

We are using image quay.io/koli/kong-ingress:v0.4.0-alpha
kubernetes version v1.8.7

Thanks in advance!

Remove the finalizer kolihub.io/kong instead of removing all finalizers from a service.
Ref: https://github.com/kolihub/kong-ingress/blob/master/pkg/controller/controller.go#L208

• Prometheus metrics
• Health checks

Trying to delete CSD (domains.platform.koli.io) and domains ("acme-org") by using below commands:
kubectl delete domain acme-org --force
kubectl delete customresourcedefinition domains.platform.koli.io --force

Some how, these are not deleting, kubectl describe csd domains.platform.koli.io gives below information,

$ kubectl describe customresourcedefinition domains.platform.koli.io
Name: domains.platform.koli.io
Namespace:
Labels:
Annotations: kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"apiextensions.k8s.io/v1beta1","kind":"CustomResourceDefinition","metadata":{"annotations":{},"name":"domains.platform.koli.io","namespac...
API Version: apiextensions.k8s.io/v1beta1
Kind: CustomResourceDefinition
Metadata:
Creation Timestamp: 2017-12-02T20:50:19Z
Deletion Grace Period Seconds: 0
Deletion Timestamp: 2017-12-03T17:10:37Z
Finalizers:
customresourcecleanup.apiextensions.k8s.io
Generation: 1
Resource Version: 225770
Self Link: /apis/apiextensions.k8s.io/v1beta1/customresourcedefinitions/domains.platform.koli.io
UID: 689e052b-d7a2-11e7-9912-fa163ee34aab
Spec:
Group: platform.koli.io
Names:
Kind: Domain
List Kind: DomainList
Plural: domains
Singular: domain
Scope: Namespaced
Version: v1
Status:
Accepted Names:
Kind: Domain
List Kind: DomainList
Plural: domains
Singular: domain
Conditions:
Last Transition Time:
Message: no conflicts found
Reason: NoConflicts
Status: True
Type: NamesAccepted
Last Transition Time: 2017-12-02T20:50:19Z
Message: the initial names have been accepted
Reason: InitialNamesAccepted
Status: True
Type: Established
Last Transition Time:
Message: could not confirm zero CustomResources remaining: timed out waiting for the condition
Reason: InstanceDeletionCheck
Status: True
Type: Terminating
Events:

Am I doing anything wrong here, how to cleanup these CSD's ? any best practices?

Every logic must be unit tested to ensure better code consistency and enable others to contribute with the project.

We should automate the process of building the code and releasing early and release versions of the code.

• Tag latest should contain the latest version of the code.
• Tag master should contain the latest version of the code in master branch.
• Tag development should contain the latest version of the code in development branch.
• Tags following Semantic versioning contain the release version of the code.

current some packages starts with "kolihub.io/kong-ingress/pkg...".
This should better work with this import "github.com/koli/kong-ingress/pkg..." ?

After "go get github.com/koli/kong-ingress" and change the package i can build without any error.

When host parameter is wrong we're getting the following event:

Field 'host' in wrong format, expecting: [name].[namespace].[domain.tld]

The expected is

Field 'host' in wrong format, expecting: [name]-[namespace].[domain.tld]

Steps to reproduce the issue:

1. Create a spec file with an unsupported host:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nodejs-app
  namespace: personal-bunny-acme
spec:
  rules:
  - host: nodejs-app.personal-bunny-acme.kolihub.io
    http:
      paths:
      - path: /
        backend:
          serviceName: nodejs-app
          servicePort: 80

2. Try to edit the spec. fixing the spec.rules.host value to nodejs-app-personal-bunny-acme.kolihub.io. The API will not be created on kong.

3. Further you can even try to delete the ingress and try to create it again with the proper host value. You won't be able to.

To fix you must delete the Ingress Pod and create the ingress again but with the correct specs.

• Add rbac examples
• Add contribution guide
• Add dev docs

When i enabled RBAC in kubernetes ,i get error as below:

Failed creating default namespace [User "system:serviceaccount:kong-system:default" cannot create namespaces at the cluster scope. (post namespaces)]

Add CI integration with travis

I'm opening this issue for discussion of how we should implement support for automated creation, deploy and renew of let's encrypt certificates.

Some related projects which we may find inspiration:

https://github.com/jetstack/kube-lego
https://github.com/kelseyhightower/kube-cert-manager

spec.status must be hidden if it's empty

The kong-ingress doesn't support custom ports, if the ingress contain any port distinct than 80 or 443 it's doesn't append the port when the upstream URL is constructed.

Related #16