You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the previous chapter we saw how we can deploy services using a holistic service resource file, in this chapter we will see how to deploy the service using configurations and route files.
22
22
23
-
Navigate to the tutorial chapter's `knative`folder:
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/04-scaling.adoc
+12-42Lines changed: 12 additions & 42 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -86,7 +86,7 @@ The last `curl` command should return a response like **Hi greeter => greeter-00
86
86
Check <<02-basic-fundas.adoc#see-what-you-have-deployed,deployed Knative resources>> for more details on which Knative objects and resources have been created with the service deployment above.
87
87
88
88
[#scaling-scale-to-zero]
89
-
== Configure scale to zero
89
+
== Configure scale-to-zero
90
90
91
91
Assuming that <<scaling-deploy-service, Greeter service>> has been deployed, once no more traffic is seen going into that service, we'd like to scale this service down to zero replicas. That's called **scale-to-zero**.
92
92
@@ -95,7 +95,7 @@ Scale-to-zero is one of the main properties making Knative a serverless platform
95
95
If another request tries to get to this revision, the activator will get it, instruct the autoscaler to create new pods for the revision as quickly as possible and buffer the request until those new pods are created.
96
96
97
97
[#scale-to-zero-formulae]
98
-
=== Calculating scale to zero time period
98
+
=== Calculating scale-to-zero time period
99
99
100
100
The Knative autoscaler uses the config map **config-autoscaler** in the **knative-serving** namespace for autoscaling related properties. The values of the attribute `stable-window` and `scale-to-zero-grace-period`, which we've seen above, are part of this config map.
101
101
@@ -131,6 +131,13 @@ As described above, the time it takes to finally scale to zero will be `STABLE_W
131
131
132
132
For easier observation let us open a new terminal and run the following command,
133
133
134
+
[source,bash,subs="+macros,+attributes"]
135
+
----
136
+
watch 'kubectl get pods -n knativetutorial'
137
+
----
138
+
139
+
.(OR)
140
+
134
141
[source,bash,subs="+macros,+attributes"]
135
142
----
136
143
watch 'oc get pods -n knativetutorial'
@@ -147,7 +154,7 @@ echo $STABLE_WINDOW
147
154
echo $SCALE_TO_ZERO_GRACE_PERIOD
148
155
----
149
156
150
-
By default the **scale-to-zero-grace-period** is `30s`, and the **stable-window** is `60s`. Firing a request to the greeter service will bring up the pod (if it is already terminated, as described above) to serve the request. Leaving it without any further requests will automatically cause it to scale to zero in `1 min 30 secs`(<<scale-to-zero-formulae,Compute scale to zero grace period>>).
157
+
By default the **scale-to-zero-grace-period** is `30s`, and the **stable-window** is `60s`. Firing a request to the greeter service will bring up the pod (if it is already terminated, as described above) to serve the request. Leaving it without any further requests will automatically cause it to scale to zero in `1 min 30 secs`(<<scale-to-zero-formulae,Compute scale-to-zero grace period>>).
Now <<scaling-invoke-service,firing the request>> to the greeter service will bring up the pod to serve the request again. Leaving it without any further requests, it will automatically scale to zero in `2 mins`(<<scale-to-zero-formulae,Compute scale to zero grace period>>)
193
-
194
-
[#scaling-observer-scale-to-zero-2m]
195
-
=== Scale to zero in 2 minute
196
-
197
-
Let us now update **scale-to-zero-grace-period** to `2m` and leave the **stable-window** to default `60s`.
198
-
199
-
[source,bash,subs="+macros,+attributes"]
200
-
----
201
-
kubectl -n knative-serving get cm config-autoscaler -o yaml | yq w - -s link:{github-repo}/{scaling-repo}/knative/configure-scaling-to-2m.yaml[configure-scaling-to-2m.yaml] | kubectl apply -f -
202
-
----
203
-
204
-
.(OR)
205
-
206
-
[source,bash,subs="+macros,+attributes"]
207
-
----
208
-
oc -n knative-serving get cm config-autoscaler -o yaml | yq w - -s link:{github-repo}/{scaling-repo}/knative/configure-scaling-to-2m.yaml[configure-scaling-to-2m.yaml] | oc apply -f -
209
-
----
210
-
211
-
Verifying the `scale-to-zero-grace-period` value, which should return `2m`:
212
-
213
-
[source,bash,subs="+macros,+attributes",linenums]
214
-
----
215
-
216
-
kubectl -n knative-serving get configmap config-autoscaler -o yaml \
217
-
| yq r - data.scale-to-zero-grace-period
218
-
----
219
-
220
-
.(OR)
221
-
222
-
[source,bash,subs="+macros,+attributes",linenums]
223
-
----
224
-
oc -n knative-serving get configmap config-autoscaler -o yaml \
225
-
| yq r - data.scale-to-zero-grace-period
226
-
----
227
-
228
-
229
-
Now <<scaling-invoke-service,firing the request>> to the greeter service will bring up the pod to serve the request and if we leave the service without any further requests, it will automatically scale to zero in `3 mins`(<<scale-to-zero-formulae,Compute scale to zero grace period>>).
199
+
Now <<scaling-invoke-service,firing the request>> to the greeter service will bring up the pod to serve the request again. Leaving it without any further requests, it will automatically scale to zero in `2 mins`(<<scale-to-zero-formulae,Compute scale-to-zero grace period>>)
230
200
231
201
[#scaling-reset-to-defaults]
232
-
=== Reset scale to zero to defaults
202
+
=== Reset scale-to-zero to defaults
233
203
234
204
Let us revert the `scale-to-zero-grace-period` to its default:
NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you dont need them any more.
282
+
NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you don't need them anymore.
<2> The username to use when authenticating with https://index.docker.io/v1/
73
73
<3> The password to use when authenticating with https://index.docker.io/v1/
74
74
75
-
For more details on why we need to do this please check https://github.com/knative/docs/blob/master/build/auth.md#basic-authentication-docker[here].
75
+
For more details on why we need to do this please check https://github.com/knative/docs/blob/master/docs/build/auth.md#basic-authentication-docker[here].
76
76
77
77
[#build-generate-build-spec]
78
78
== Generate Knative build spec
79
-
The knative build spec is used to create and run the knative builds. You can find more details on Knative build https://github.com/knative/docs/tree/master/build[here].
79
+
The knative build spec is used to create and run the knative builds. You can find more details on Knative build https://github.com/knative/docs/tree/master/docs/build[here].
<1> The kubernetes secret called `basic-auth-pass`, check https://github.com/knative/docs/blob/master/build/auth.md#basic-authentication-docker[here] for more details
226
-
<2> The kubernetes service account called `build-bot` that wll run the build. Only `build-bot`as access to the secret `basic-auth-pass`. Check https://github.com/knative/docs/blob/master/build/auth.md#basic-authentication-docker[here] for more details
225
+
<1> The kubernetes secret called `basic-auth-pass`, check https://github.com/knative/docs/blob/master/docs/build/auth.md#basic-authentication-docker[here] for more details
226
+
<2> The kubernetes service account called `build-bot` that wll run the build. Only `build-bot`has access to the secret `basic-auth-pass`. Check https://github.com/knative/docs/blob/master/docs/build/auth.md#basic-authentication-docker[here] for more details
227
227
<3> the kubernetes persistence volume claim used to cache maven artifacts, to make subsequent builds faster
228
228
<4> the kubernetes persistence volume claim that will be used to cache docker base images to make subsequent https://github.com/GoogleContainerTools/kaniko[Kaniko] docker builds faster
NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you dont need them any more.
356
+
NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you don't need them anymore.
NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you dont need them any more.
216
+
NOTE: You can also delete xref:ROOT:05-build/build.adoc#build-apply-prereq-resources[pre-req resources] that were created if you don't need them anymore.
Copy file name to clipboardExpand all lines: documentation/modules/ROOT/pages/06-eventing/eventing.adoc
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -14,7 +14,7 @@ At the end of this chapter you will know and understand:
14
14
include::partial$prereq-cli.adoc[]
15
15
16
16
[#eventing-assumptions]
17
-
== Assumption
17
+
== Assumptions
18
18
19
19
You have completed the xref:ROOT:05-build/build.adoc[Build] or xref:ROOT:05-build/build-templates.adoc[Build Templates], as you will be using the container image `event-greeter:0.0.1` or `event-greeter:0.0.2` in this chapter.
0 commit comments