-
Notifications
You must be signed in to change notification settings - Fork 346
/
doc.go
192 lines (162 loc) · 5.42 KB
/
doc.go
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
/*
Package kubernetes implements Kubernetes Ingress support for Skipper.
See: http://kubernetes.io/docs/user-guide/ingress/
The package provides a Skipper DataClient implementation that can be used to access the Kubernetes API for
ingress resources and generate routes based on them. The client polls for the ingress settings, and there is no
need for a separate controller. On the other hand, it doesn't provide a full Ingress solution alone, because it
doesn't do any load balancer configuration or DNS updates. For a full Ingress solution, it is possible to use
Skipper together with Kube-ingress-aws-controller, which targets AWS and takes care of the load balancer setup
for Kubernetes Ingress.
See: https://github.com/zalando-incubator/kube-ingress-aws-controller
Both Kube-ingress-aws-controller and Skipper Kubernetes are part of the larger project, Kubernetes On AWS:
https://github.com/zalando-incubator/kubernetes-on-aws/
# Ingress shutdown by healthcheck
The Kubernetes ingress client catches TERM signals when the ProvideHealthcheck option is enabled, and reports
failing healthcheck after the signal was received. This means that, when the Ingress client is responsible for
the healthcheck of the cluster, and the Skipper process receives the TERM signal, it won't exit by itself
immediately, but will start reporting failures on healthcheck requests. Until it gets killed by the kubelet,
Skipper keeps serving the requests in this case.
# Example - Ingress
A basic ingress specification:
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
# Example - Ingress with ratelimiting
The example shows 50 calls per minute are allowed to each skipper
instance for the given ingress.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/ratelimit: ratelimit(50, "1m")
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
# Example - Ingress with client based ratelimiting
The example shows 3 calls per minute per client, based on
X-Forwarded-For header or IP incase there is no X-Forwarded-For header
set, are allowed to each skipper instance for the given ingress.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/ratelimit: localRatelimit(3, "1m")
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
The example shows 500 calls per hour per client, based on
Authorization header set, are allowed to each skipper instance for the
given ingress.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/ratelimit: localRatelimit(500, "1h", "auth")
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
# Example - Ingress with custom skipper filter configuration
The example shows the use of 2 filters from skipper for the implicitly
defined route in ingress.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/skipper-filter: localRatelimit(50, "10m") -> requestCookie("test-session", "abc")
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
# Example - Ingress with custom skipper Predicate configuration
The example shows the use of a skipper predicates for the implicitly
defined route in ingress.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/skipper-predicate: QueryParam("query", "^example$")
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
# Example - Ingress with custom skipper Routes configuration
The example shows the use of custom skipper routes which be additional to the
routes generated for the ingress.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/skipper-routes: |
Method("OPTIONS") ->
setResponseHeader("Access-Control-Allow-Origin", "*") ->
setResponseHeader("Access-Control-Allow-Methods", "GET, OPTIONS") ->
setResponseHeader("Access-Control-Allow-Headers", "Authorization") ->
status(200) -> <shunt>
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
# Example - Ingress with shadow traffic
This will send production traffic to app-default.example.org and
copies incoming requests to https://app.shadow.example.org, but drops
responses from shadow URL. This is helpful to test your next
generation software with production workload. See also
https://godoc.org/github.com/zalando/skipper/filters/tee for details.
apiVersion: extensions/v1beta1
kind: Ingress
Metadata:
annotations:
zalando.org/skipper-filter: tee("https://app.shadow.example.org")
name: app
spec:
rules:
- host: app-default.example.org
http:
paths:
- backend:
serviceName: app-svc
servicePort: 80
*/
package kubernetes