Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
k8s-ingress
Project
Project
Details
Activity
Releases
Cycle Analytics
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Charts
Issues
0
Issues
0
List
Board
Labels
Milestones
Merge Requests
3
Merge Requests
3
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Charts
Create a new issue
Commits
Issue Boards
Open sidebar
uplex-varnish
k8s-ingress
Commits
78ae6f86
Commit
78ae6f86
authored
Nov 21, 2018
by
Geoff Simmons
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Add a README to the examples/ folder.
parent
9cbf4214
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
81 additions
and
0 deletions
+81
-0
README.md
examples/README.md
+81
-0
No files found.
examples/README.md
0 → 100644
View file @
78ae6f86
# Example Ingress
The YAML configurations in this folder create sample Services and an
Ingress to test and demonstrate the Ingress implementation -- the
"cafe" example, inspired by existing Ingress projects.
```
# Create the Services "coffee-svc" and "tea-svc"
$ kubectl create -f cafe.yaml
# Create an Ingress that routes requests to the two Services
$ kubectl create -f cafe-ingress.yaml
```
To note:
*
The Ingress has the annotation
``kubernetes.io/ingress.class:
"varnish"``
, identifying it as an Ingress to be implemented by the
Varnish controller (the Varnish controller ignores any Ingress that
does not have this annotation).
*
Both the Ingress and the Services are created in the
``varnish-ingress``
namespace, as are the resources defined by the
configurations in the
[
``deploy/``
](
/deploy
)
folder. The controller
currently ignores all definitions that are not defined in the same
namespace as the Pod in which it is running (this is likely to
become more flexible in future development).
The Ingress rules in the example require that:
*
Every request has
``cafe.example.com``
as the value of its
``Host``
header.
*
Otherwise, Varnish answers with a synthetic 404 Not Found
response.
*
If the URL path begins with
``/tea``
, then the request is routed
to the Service
``tea-svc``
.
*
If the path begins with
``/coffee``
, then the request is routed
to the Service
``coffee-svc``
.
*
For any other URL path, Varnish responds with 404 Not Found.
In the following, assume that
``$ADDR``
is the external address at
which the Kubernetes cluster receives requests, and that
``$PORT``
is
the external port for which requests are received by Varnish. (For example,
the port may have resulted from the NodePort definition in
[
``deploy/nodeport.yaml``
](
/deploy/nodeport.yaml
)
.)
Then for this curl command:
```
$ curl -H 'Host: cafe.example.com' 'http://$ADDR:$PORT/coffee/foo/bar
```
... you may receive a response body like this:
```
Server address: 172.17.0.17:80
Server name: coffee-6c47b9cb9c-ldljf
Date: 21/Nov/2018:15:58:47 +0000
URI: /coffee
Request ID: f78d60f0d578792fa76a114d9cb73798
```
The "Server address" and "Server name" values indicate that the
response was generated by the coffee Service.
For this command:
```
$ curl -H 'Host: cafe.example.com' 'http://$ADDR:$PORT/tea/baz/quux
```
... you may receive a response body like this:
```
Server address: 172.17.0.12:80
Server name: tea-58d4697745-wq278
Date: 21/Nov/2018:16:05:32 +0000
URI: /tea/baz/quux
Request ID: 5cffc81f3be0d98d005257f39c874693
```
This response was generated by the tea Service.
These commands lead to a 404 Not Found response for the reasons given:
```
# Does not include the required Host header
$ curl 'http://$ADDR:$PORT/coffee/foo/bar
# URL path does not begin with either of /coffee or /tea
$ curl -H 'Host: cafe.example.com' 'http://$ADDR:$PORT/milk
```
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment