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
Copy file name to clipboardExpand all lines: applications/deployments/deployment-strategies.adoc
+8-22Lines changed: 8 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,23 +1,15 @@
1
1
[id="deployment-strategies"]
2
-
= Using DeploymentConfig strategies
2
+
= Using deployment strategies
3
3
include::modules/common-attributes.adoc[]
4
4
:context: deployment-strategies
5
5
6
6
toc::[]
7
7
8
-
A _deployment strategy_ is a way to change or upgrade an application. The aim
9
-
is to make the change without downtime in a way that the user barely notices the
10
-
improvements.
8
+
A _deployment strategy_ is a way to change or upgrade an application. The aim is to make the change without downtime in a way that the user barely notices the improvements.
11
9
12
-
Because the end user usually accesses the application through a route handled by
13
-
a router, the deployment strategy can focus on DeploymentConfig features or
14
-
routing features. Strategies that focus on the DeploymentConfig impact all
15
-
routes that use the application. Strategies that use router features target
16
-
individual routes.
10
+
Because the end user usually accesses the application through a route handled by a router, the deployment strategy can focus on `DeploymentConfig` object features or routing features. Strategies that focus on the deployment impact all routes that use the application. Strategies that use router features target individual routes.
17
11
18
-
Many deployment strategies are supported through the DeploymentConfig, and some
19
-
additional strategies are supported through router features. DeploymentConfig
20
-
strategies are discussed in this section.
12
+
Many deployment strategies are supported through the `DeploymentConfig` object, and some additional strategies are supported through router features. Deployment strategies are discussed in this section.
Consider the following when choosing a deployment strategy:
36
28
37
29
- Long-running connections must be handled gracefully.
38
-
- Database conversions can be complex and must be done and rolled back along with
39
-
the application.
40
-
- If the application is a hybrid of microservices and traditional components,
41
-
downtime might be required to complete the transition.
30
+
- Database conversions can be complex and must be done and rolled back along with the application.
31
+
- If the application is a hybrid of microservices and traditional components, downtime might be required to complete the transition.
42
32
- You must have the infrastructure to do this.
43
-
- If you have a non-isolated test environment, you can break both new and old
44
-
versions.
33
+
- If you have a non-isolated test environment, you can break both new and old versions.
45
34
46
-
A deployment strategy uses readiness checks to determine if a new Pod is ready
47
-
for use. If a readiness check fails, the DeploymentConfig retries to run the
48
-
Pod until it times out. The default timeout is `10m`, a value set in
49
-
`TimeoutSeconds` in `dc.spec.strategy.*params`.
35
+
A deployment strategy uses readiness checks to determine if a new pod is ready for use. If a readiness check fails, the `DeploymentConfig` object retries to run the pod until it times out. The default timeout is `10m`, a value set in `TimeoutSeconds` in `dc.spec.strategy.*params`.
DeploymentConfigs can be managed from the {product-title} web console's
12
-
*Workloads* page or using the `oc` CLI. The following procedures show CLI usage
13
-
unless otherwise stated.
11
+
`DeploymentConfig` objects can be managed from the {product-title} web console's *Workloads* page or using the `oc` CLI. The following procedures show CLI usage unless otherwise stated.
Deployment strategies provide a way for the application to evolve. Some
9
-
strategies use DeploymentConfigs to make changes that are seen by users of all
10
-
routes that resolve to the application. Other advanced strategies, such as the
11
-
ones described in this section, use router features in conjunction with
12
-
DeploymentConfigs to impact specific routes.
8
+
Deployment strategies provide a way for the application to evolve. Some strategies use `DeploymentConfig` objects to make changes that are seen by users of all routes that resolve to the application. Other advanced strategies, such as the ones described in this section, use router features in conjunction with DeploymentConfig` objects to impact specific routes.
The most common route-based strategy is to use a _blue-green deployment_. The
26
-
new version (the blue version) is brought up for testing and evaluation, while
27
-
the users still use the stable version (the green version). When ready, the
28
-
users are switched to the blue version. If a problem arises, you can switch back
29
-
to the green version.
30
-
31
-
A common alternative strategy is to use _A/B versions_ that are both active at
32
-
the same time and some users use one version, and some users use the other
33
-
version. This can be used for experimenting with user interface changes and
34
-
other features to get user feedback. It can also be used to verify proper
35
-
operation in a production context where problems impact a limited number of
36
-
users.
37
-
38
-
A canary deployment tests the new version but when a problem is detected it
39
-
quickly falls back to the previous version. This can be done with both of the
40
-
above strategies.
41
-
42
-
The route-based deployment strategies do not scale the number of Pods in the
43
-
services. To maintain desired performance characteristics the deployment
44
-
configurations might have to be scaled.
21
+
The most common route-based strategy is to use a _blue-green deployment_. The new version (the blue version) is brought up for testing and evaluation, while the users still use the stable version (the green version). When ready, the users are switched to the blue version. If a problem arises, you can switch back to the green version.
22
+
23
+
A common alternative strategy is to use _A/B versions_ that are both active at the same time and some users use one version, and some users use the other version. This can be used for experimenting with user interface changes and other features to get user feedback. It can also be used to verify proper operation in a production context where problems impact a limited number of users.
24
+
25
+
A canary deployment tests the new version but when a problem is detected it quickly falls back to the previous version. This can be done with both of the above strategies.
26
+
27
+
The route-based deployment strategies do not scale the number of pods in the services. To maintain desired performance characteristics the deployment configurations might have to be scaled.
Copy file name to clipboardExpand all lines: applications/deployments/what-deployments-are.adoc
+8-22Lines changed: 8 additions & 22 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,23 +1,15 @@
1
1
[id="what-deployments-are"]
2
-
= Understanding Deployments and DeploymentConfigs
2
+
= Understanding `Deployment` and `DeploymentConfig` objects
3
3
include::modules/common-attributes.adoc[]
4
4
:context: what-deployments-are
5
5
6
6
toc::[]
7
7
8
-
_Deployments_ and _DeploymentConfigs_ in {product-title} are API objects that
9
-
provide two similar but different methods for fine-grained management over
10
-
common user applications. They are composed of the following separate API
11
-
objects:
8
+
The `Deployment` and `DeploymentConfig` API objects in {product-title} provide two similar but different methods for fine-grained management over common user applications. They are composed of the following separate API objects:
12
9
13
-
- A DeploymentConfig or a Deployment, either of which describes the desired state
14
-
of a particular component of the application as a Pod template.
15
-
- DeploymentConfigs involve one or more _ReplicationControllers_, which contain a
16
-
point-in-time record of the state of a DeploymentConfig as a Pod template.
17
-
Similarly, Deployments involve one or more _ReplicaSets_, a successor of
18
-
ReplicationControllers.
19
-
- One or more Pods, which represent an instance of a particular version of an
20
-
application.
10
+
* A `DeploymentConfig` or `Deployment` object, either of which describes the desired state of a particular component of the application as a pod template.
11
+
* `DeploymentConfig` objects involve one or more _replication controllers_, which contain a point-in-time record of the state of a deployment as a pod template. Similarly, `Deployment` objects involve one or more _replica sets_, a successor of replication controllers.
12
+
* One or more pods, which represent an instance of a particular version of an application.
Deployments and DeploymentConfigs are enabled by the use of native Kubernetes
40
-
API objects ReplicaSets and ReplicationControllers, respectively, as their
41
-
building blocks.
31
+
Deployments and deployment configs are enabled by the use of native Kubernetes API objects `ReplicaSet` and `ReplicationController`, respectively, as their building blocks.
42
32
43
-
Users do not have to manipulate ReplicationControllers, ReplicaSets, or Pods
44
-
owned by DeploymentConfigs or Deployments. The deployment systems ensures
45
-
changes are propagated appropriately.
33
+
Users do not have to manipulate replication controllers, replica sets, or pods owned by `DeploymentConfig` objects or deployments. The deployment systems ensure changes are propagated appropriately.
46
34
47
35
[TIP]
48
36
====
49
-
If the existing deployment strategies are not suited for your use case and you
50
-
must run manual steps during the lifecycle of your deployment, then
51
-
you should consider creating a Custom deployment strategy.
37
+
If the existing deployment strategies are not suited for your use case and you must run manual steps during the lifecycle of your deployment, then you should consider creating a custom deployment strategy.
52
38
====
53
39
54
40
The following sections provide further details on these objects.
Cluster administrators can idle applications to reduce resource consumption.
9
-
This is useful when the cluster is deployed on a public cloud where cost is
10
-
related to resource consumption.
8
+
Cluster administrators can idle applications to reduce resource consumption. This is useful when the cluster is deployed on a public cloud where cost is related to resource consumption.
11
9
12
-
If any scalable resources are not in use, {product-title} discovers and idles
13
-
them by scaling their replicas to `0`. The next time network traffic is directed
14
-
to the resources, the resources are unidled by scaling up the replicas, and
15
-
normal operation continues.
10
+
If any scalable resources are not in use, {product-title} discovers and idles them by scaling their replicas to `0`. The next time network traffic is directed to the resources, the resources are unidled by scaling up the replicas, and normal operation continues.
16
11
17
-
Applications are made of services, as well as other scalable resources, such as
18
-
DeploymentConfigs. The action of idling an application involves idling
19
-
all associated resources.
12
+
Applications are made of services, as well as other scalable resources, such as deployment configs. The action of idling an application involves idling all associated resources.
Copy file name to clipboardExpand all lines: applications/projects/working-with-projects.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
@@ -10,7 +10,7 @@ isolation from other communities.
10
10
11
11
[NOTE]
12
12
====
13
-
Projects starting with `openshift-` and `kube-` are xref:../../authentication/using-rbac.adoc#rbac-default-projects_using-rbac[default projects]. These projects host cluster components that run as Pods and other infrastructure components. As such, {product-title} does not allow you to create Projects starting with `openshift-` or `kube-` using the `oc new-project` command. Cluster administrators can create these Projects using the `oc adm new-project` command.
13
+
Projects starting with `openshift-` and `kube-` are xref:../../authentication/using-rbac.adoc#rbac-default-projects_using-rbac[default projects]. These projects host cluster components that run as pods and other infrastructure components. As such, {product-title} does not allow you to create projects starting with `openshift-` or `kube-` using the `oc new-project` command. Cluster administrators can create these projects using the `oc adm new-project` command.
A multi-project quota, defined by a ClusterResourceQuota object, allows quotas
9
-
to be shared across multiple projects. Resources used in each selected project
10
-
are aggregated and that aggregate is used to limit resources across all the
11
-
selected projects.
8
+
A multi-project quota, defined by a `ClusterResourceQuota` object, allows quotas to be shared across multiple projects. Resources used in each selected project are aggregated and that aggregate is used to limit resources across all the selected projects.
12
9
13
-
This guide describes how cluster administrators can set and manage resource
14
-
quotas across multiple projects.
10
+
This guide describes how cluster administrators can set and manage resource quotas across multiple projects.
A _resource quota_, defined by a ResourceQuota object, provides constraints that
9
-
limit aggregate resource consumption per project. It can limit the quantity of
10
-
objects that can be created in a project by type, as well as the total amount of
11
-
compute resources and storage that may be consumed by resources in that project.
8
+
A _resource quota_, defined by a `ResourceQuota` object, provides constraints that limit aggregate resource consumption per project. It can limit the quantity of objects that can be created in a project by type, as well as the total amount of compute resources and storage that might be consumed by resources in that project.
12
9
13
-
This guide describes how resource quotas work, how cluster administrators can
14
-
set and manage resource quotas on a per project basis, and how developers and
15
-
cluster administrators can view them.
10
+
This guide describes how resource quotas work, how cluster administrators can set and manage resource quotas on a per project basis, and how developers and cluster administrators can view them.
Copy file name to clipboardExpand all lines: modules/application-health-about.adoc
+9-10Lines changed: 9 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,7 +12,7 @@ You can include one or more probes in the specification for the pod that contain
12
12
13
13
[NOTE]
14
14
====
15
-
If you want to add or edit health checks in an existing pod, you must edit the pod deployment configuration or use the *Developer* perspective in the web console. You cannot use the CLI to add or edit health checks for an existing pod.
15
+
If you want to add or edit health checks in an existing pod, you must edit the pod `DeploymentConfig` object or use the *Developer* perspective in the web console. You cannot use the CLI to add or edit health checks for an existing pod.
16
16
====
17
17
18
18
Readiness probe::
@@ -34,7 +34,7 @@ A _startup probe_ indicates whether the application within a container is starte
34
34
+
35
35
Some applications can require additional start-up time on their first initialization. You can use a startup probe with a liveness or readiness probe to delay that probe long enough to handle lengthy start-up time using the `failureThreshold` and `periodSeconds` parameters.
36
36
+
37
-
For example, you can add a startup probe, with a `failureThreshold` of 30 failures and a `periodSeconds` of 10 seconds (30 * 10s = 300s) for a maximum of 5 minutes, to a liveness probe. After the startup probe succeeds the first time, the liveness probe takes over.
37
+
For example, you can add a startup probe, with a `failureThreshold` of 30 failures and a `periodSeconds` of 10 seconds (30 * 10s = 300s) for a maximum of 5 minutes, to a liveness probe. After the startup probe succeeds the first time, the liveness probe takes over.
38
38
39
39
You can configure liveness, readiness, and startup probes with any of the following types of tests:
40
40
@@ -53,11 +53,11 @@ You can configure several fields to control the behavior of a probe:
53
53
* `initialDelaySeconds`: The time, in seconds, after the container starts before the probe can be scheduled. The default is 0.
54
54
* `periodSeconds`: The delay, in seconds, between performing probes. The default is `10`.
55
55
* `timeoutSeconds`: The number of seconds of inactivity after which the probe times out and the container is assumed to have failed. The default is `1`.
56
-
* `successThreshold`: The number of times that the probe must report success after a failure in order to reset the container status to successful. The value must be `1` for a liveness probe. The default is `1`.
57
-
* `failureThreshold`: The number of times that the probe is allowed to fail. The default is 3. After the specified attempts:
58
-
** for a liveness probe, the container is restarted
56
+
* `successThreshold`: The number of times that the probe must report success after a failure in order to reset the container status to successful. The value must be `1` for a liveness probe. The default is `1`.
57
+
* `failureThreshold`: The number of times that the probe is allowed to fail. The default is 3. After the specified attempts:
58
+
** for a liveness probe, the container is restarted
59
59
** for a readiness probe, the pod is marked `Unready`
60
-
** for a startup probe, the container is killed and is subject to the pod's `restartPolicy`
60
+
** for a startup probe, the container is killed and is subject to the pod's `restartPolicy`
61
61
+
62
62
[NOTE]
63
63
====
@@ -71,7 +71,7 @@ liveness or readiness probes, as shown in the examples.
71
71
[id="application-health-examples"]
72
72
== Example probes
73
73
74
-
The following are samples of different probes as they would appear in an object specification.
74
+
The following are samples of different probes as they would appear in an object specification.
75
75
76
76
.Sample readiness probe with a container command readiness probe in a pod spec
77
77
[source,yaml]
@@ -166,7 +166,7 @@ spec:
166
166
command: <5>
167
167
- /bin/bash
168
168
- '-c'
169
-
- timeout 60 /opt/eap/bin/livenessProbe.sh
169
+
- timeout 60 /opt/eap/bin/livenessProbe.sh
170
170
periodSeconds: 10 <6>
171
171
successThreshold: 1 <7>
172
172
failureThreshold: 3 <8>
@@ -178,7 +178,7 @@ spec:
178
178
<3> The liveness probe.
179
179
<4> The type of probe, here a container command probe.
180
180
<5> The command line to execute inside the container.
181
-
<6> How often in seconds to perform the probe.
181
+
<6> How often in seconds to perform the probe.
182
182
<7> The number of number of consecutive successes needed to show success after a failure.
183
183
<8> The number of times to try the probe after a failure.
0 commit comments