blog for setting up ingress with Istio

[devadvocado]

Cross-posting a popular ingress+Istio blog I posted on the Kubernetes blog that I think would be of interest to the Istio community.

[ ] Configuration Infrastructure
[X] Docs
[ ] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Policies and Telemetry
[ ] Security
[ ] Test and Release
[ ] User Experience
[ ] Developer Infrastructure

[istio-policy-bot]

😊 Welcome! This is either your first contribution to the Istio documentation repo, or
it's been awhile since you've been here. A few things you should know:

• You can learn about how we write and maintain documentation, about our style guidelines,
  and about all the available web site features by visiting Contributing to the Docs.

• In the next few minutes, an automatic preview of your change will be
  built as a full copy of the istio.io website. You can find this preview by clicking on
  the Details link next to the deploy/netlify entry in the Status section of this
  page.

• We care about quality, so we've put in place a number of checks to ensure our documentation
  is top notch. We do spell checking, we sanitize the markdown, we ensure all hyperlinks point
  to valid location, and more. If your PR doesn't pass one of these checks, you'll see a red X in the
  status section of the page. Click on the Details link to get a list of the problems with your PR.
  Fix those problems and push an update to your PR. This will automatically rerun the tests and
  hopefully this time everything will be perfect.

• Once your changes are accepted and merged into the repository, they will initially show up
  on https://preliminary.istio.io. The changes will be published to https://istio.io
  the next time we do a major release (which typically happens every 3 months or so).

Thanks for contributing!

Courtesy of your friendly welcome wagon.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[istio-testing]

Hi @devadvocado. Thanks for your PR.

I'm waiting for a istio member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[ericvn]

/ok-to-test

[istio-testing]

@devadvocado: The following test failed, say /retest to rerun all failed tests:

Test name	Commit	Details	Rerun command
lint_istio.io	2e85d7a	link	/test lint_istio.io

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[frankbu]

@devadvocado This doesn't seem appropriate for the Istio blog. Other than using the Istio bookinfo services as the backend application, it doesn't demonstrate any interesting use of Istio. Also, it uses Kong as a k8s Ingress controller while Istio doesn't even recommend using k8s Ingress at all. Istio uses an Istio Gateway for edge routing instead. A Kong/ingress article on the Istio blog would be expected to explain how it compares to the Istio Gateway it replaces (pros/cons). For example, with an Istio Gateway, a VirtualService handles the edge routing, etc., so what functionality of that approach is available, lost, or replaced when using Kong for Ingress?

cc @rshriram @louiscryan

[linsun]

@devadvocado I second Frank's concern. Is there anything that is istio related other than bookinfo examples?

[linsun]

cc @istio/steering-committee

[devadvocado]

@frankbu @linsun thanks for the reviewing and feedback! Quite honestly, I was just reposting an Istio related blog post we published on the Kubernetes blog that got us some great feedback. But I will review your feedback, rewrite, and republish something that fits better for the Istio community. Thanks!

[rshriram]

@devadvocado thanks for your contribution. I think the concern that @linsun / @frankbu have is about the lack of additional explanation in this article regarding the motivations for doing this kind of integration. It is true that in Istio, we allow legacy ingress controller implementations to co-exist with the Istio gateway, and that the technique you have followed is essentially what some of our users follow when deploying the nginx ingress controller with Istio.

My suggestions are as follows:

Explain the motivation upfront - e.g., “for those who are already using Kong for API management and want to continue using it while taking advantage of Istio for service mesh capabilities like advanced routing, built in mtls, authz, reliability knobs, uniform observability, etc., here is a demo explaining how you can do so”. or something along these lines..

Now, with regard to the technique itself, what you have written works but is not the best way to take full advantage of both solutions. Instead, I suggest you try this:

1. Deploy Istio gateway container and the Kong container in the same pod (you can either inject the kong container specs into the gateway container or vice versa, and have a link to this yaml)
2. Configure kong (as usual) but set all the destinations to 127.0.0.1:15080 or some port that is not exposed by the k8s service.
3. Configure Istio ingress gateway plaintext http servers with the same port 15080 (following the standard Istio gateway tasks).

Essentially, you are forwarding all traffic from Kong to the Istio gateway on the localhost port 15080. From there on, its business as usual, with Istio gateway doing its thing, forwarding traffic. The performance profile should be the same as what you currently have, except you wont need iptables traffic capture.

The benefit of this model is that users get the best of both systems. You can configure Kong natively using whatever APIs you have, instead of using the limited k8s ingress api filled with annotations. At the same time, you can configure/control the Istio gateways with the native APIs.

If you dont feel like trying out this technique, you can fallback to the existing model but make it a point to clearly explain how the features align.. Something like, "Kong ingress controller handles inbound traffic, performs api management tasks, and then hands it over to istio sidecars that in turn take care of automatic mutual tls, authorization, reliability (through virtual services, destination rules, etc.), metrics and tracing, etc.". We have refrained from publishing this way of integration as a dedicated task purely because its pretty clunky, hacky and has a string of issues we have seen in the past. But we still support it to interoperate with legacy ingress controller solutions.