Disabling Health Check Promotion in OpenShift for Deployment with Zero Replicas

When working with OpenShift, there are times when you need to deploy a module without triggering the usual health check promotion pipeline. This might be necessary for various reasons, such as performing maintenance or updating the application with zero downtime. In this blog post, we’ll go over how to temporarily disable the production module health check promotion pipeline to facilitate a deployment with zero replicas.

Why Disable Health Check Promotion?

By default, OpenShift uses health checks to ensure that each module is running correctly before promoting it to production. However, there are scenarios where you may want to bypass these checks temporarily, such as when:

• Deploying updates or patches that don't require immediate scaling.

• Performing maintenance tasks that necessitate starting with zero replicas.

• Preparing an environment for a controlled deployment where immediate promotion isn't desired.

Steps to Disable Health Check Promotion

• Access Your OpenShift Console:
  Begin by logging into your OpenShift console. Ensure you have the appropriate permissions to modify deployment configurations.

• Navigate to the Deployment Configuration:
  Find the deployment configuration (DC) of the module you wish to modify. This can typically be found under the "Workloads" section in the OpenShift console.

• Edit the Deployment Configuration:
  Click on the module's deployment configuration to edit it. You'll need to adjust the settings to temporarily disable health checks.

• Set the Replicas to Zero:
  Adjust the replicas field in your deployment configuration to 0. This ensures that no pods are running during the initial stage of deployment.

• Disable Health Check Promotion:
  Locate the health check settings in the deployment configuration. These are often found under the "Health Checks" tab or section. Temporarily disable the readiness and liveness probes to prevent the deployment pipeline from promoting the module based on health checks.

• Apply Changes:
  Save and apply your changes to the deployment configuration. This will update the configuration and disable the health check promotion for this module.

• Deploy Your Module:
  With health checks disabled and replicas set to zero, you can now deploy your module without triggering the health check promotion pipeline. This setup allows for controlled updates or maintenance without the usual checks and balances.

• Re-enable Health Checks After Deployment:
  Once your deployment or maintenance task is complete, remember to re-enable the health checks and adjust the replicas back to the desired number to resume normal operations.

Reach on CRC

CRC start

WARN A new version (2.41.0) has been published on https://developers.redhat.com/content-gateway/file/pub/openshift-v4/clients/crc/2.41.0/crc-windows-installer.zip INFO Using bundle path C:\Users\Pexabo\.crc\cache\crc_hyperv_4.16.4_amd64.crcbundle INFO Checking minimum RAM requirements INFO Check if Podman binary exists in: C:\Users\Pexabo\.crc\bin\oc INFO Checking if running in a shell with administrator rights WARN Preflight checks failed duringcrc start, please try to runcrc setupfirst in case you haven't done so yet crc should be run in a shell without administrator rights

None Admin

I have the url in my hand to logi at the end

one more run to enter

Deployment config is all empty

I have an app there that is running

go lang running pod there

Create the deployment Config

llm nuggets for you

For view makes it easier

Deployments are not empty

only running with one

gpt in action to write the deployment

To create a Kubernetes Deployment with 3 replicas based on the given Pod specification, you'll need to use a Deployment object. The Deployment will manage the creation and scaling of the specified Pod replicas. Below is the YAML configuration for a Deployment with 3 replicas:

apiVersion: apps/v1
kind: Deployment
metadata:
name: golang-ex-deployment
namespace: myapp-project
spec:
replicas: 3
selector:
matchLabels:
app: golang-ex
template:
metadata:
labels:
app: golang-ex
spec:
restartPolicy: Always
serviceAccountName: default
imagePullSecrets:
- name: default-dockercfg-xlv29
priority: 0
schedulerName: default-scheduler
enableServiceLinks: true
terminationGracePeriodSeconds: 30
preemptionPolicy: PreemptLowerPriority
securityContext:
seLinuxOptions:
level: 's0:c26,c5'
fsGroup: 1000660000
seccompProfile:
type: RuntimeDefault
containers:
- name: golang-ex
image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2'
resources: {}
volumeMounts:
- name: kube-api-access-kmdlt
readOnly: true
mountPath: /var/run/secrets/kubernetes.io/serviceaccount
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: IfNotPresent
securityContext:
capabilities:
drop:
- ALL
runAsUser: 1000660000
runAsNonRoot: true
allowPrivilegeEscalation: false
serviceAccount: default
volumes:
- name: kube-api-access-kmdlt
projected:
sources:
- serviceAccountToken:
expirationSeconds: 3607
path: token
- configMap:
name: kube-root-ca.crt
items:
- key: ca.crt
path: ca.crt
- downwardAPI:
items:
- path: namespace
fieldRef:
apiVersion: v1
fieldPath: metadata.namespace
- configMap:
name: openshift-service-ca.crt
items:
- key: service-ca.crt
path: service-ca.crt
defaultMode: 420
dnsPolicy: ClusterFirst
tolerations:
- key: node.kubernetes.io/not-ready
operator: Exists
effect: NoExecute
tolerationSeconds: 300
- key: node.kubernetes.io/unreachable
operator: Exists
effect: NoExecute
tolerationSeconds: 300

Key Points of This Deployment YAML:

• Replicas: Set to 3 to ensure three instances of the pod are running.

• Selector: Matches the label app: golang-ex to ensure the Deployment manages pods with this label.

• Template: The pod template in the Deployment matches the provided pod specification, including all containers, volumes, and security contexts.

Apply this configuration with kubectl:

kubectl apply -f deployment.yaml

Replace deployment.yaml with the file name you saved the YAML configuration in. This command will create the Deployment and manage 3 replicas of the specified pod.

Trigger and see 3

no label is mine

Running pods

When i created it

Delete pod and it goes back up

Process in the back >>> train engines

Replica Set Given by GPT

apiVersion: apps/v1 kind: Deployment metadata: name: golang-ex-deployment namespace: myapp-project spec: replicas: 3 selector: matchLabels: app: golang-ex template: metadata: labels: app: golang-ex spec: restartPolicy: Always serviceAccountName: default imagePullSecrets: - name: default-dockercfg-xlv29 priority: 0 schedulerName: default-scheduler enableServiceLinks: true terminationGracePeriodSeconds: 30 preemptionPolicy: PreemptLowerPriority securityContext: seLinuxOptions: level: 's0:c26,c5' fsGroup: 1000660000 seccompProfile: type: RuntimeDefault containers: - name: golang-ex image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2' resources: {} volumeMounts: - name: kube-api-access-kmdlt readOnly: true mountPath: /var/run/secrets/kubernetes.io/serviceaccount terminationMessagePath: /dev/termination-log terminationMessagePolicy: File imagePullPolicy: IfNotPresent securityContext: capabilities: drop: - ALL runAsUser: 1000660000 runAsNonRoot: true allowPrivilegeEscalation: false serviceAccount: default volumes: - name: kube-api-access-kmdlt projected: sources: - serviceAccountToken: expirationSeconds: 3607 path: token - configMap: name: kube-root-ca.crt items: - key: ca.crt path: ca.crt - downwardAPI: items: - path: namespace fieldRef: apiVersion: v1 fieldPath: metadata.namespace - configMap: name: openshift-service-ca.crt items: - key: service-ca.crt path: service-ca.crt defaultMode: 420 dnsPolicy: ClusterFirst tolerations: - key: node.kubernetes.io/not-ready operator: Exists effect: NoExecute tolerationSeconds: 300 - key: node.kubernetes.io/unreachable operator: Exists effect: NoExecute tolerationSeconds: 300

in the source

in yaml just the generic code is there

Lets Analyse

The provided YAML configuration is for a Kubernetes Deployment resource, which defines a set of pods to be managed by Kubernetes. Each line in the configuration specifies particular settings and options for the deployment, including its metadata, the pod template, the number of replicas, and various other settings related to the runtime environment of the pods.

Here's a line-by-line breakdown of the YAML:

• apiVersion: apps/v1
  Specifies the version of the Kubernetes API being used for this configuration. apps/v1 is a stable version used for deployments.

• kind: Deployment
  Declares the type of Kubernetes object being defined. In this case, it is a Deployment, which manages a set of replicated pods for application scaling and updates.

• metadata:
  Metadata provides information about the deployment such as its name and namespace.

• name: golang-ex-deployment
  The name of the deployment, used to identify it within the namespace.

• namespace: myapp-project
  The namespace in which this deployment is created. Namespaces provide a scope for Kubernetes objects and help organize resources.

• spec:
  The specification of the desired behavior of the deployment, detailing the number of replicas, the template for creating pods, and other settings.

• replicas: 3
  Indicates that three replicas (instances) of the pod defined in the template should be maintained.

• selector:
  Defines how the deployment identifies the set of pods to manage. This is done using labels.

• matchLabels:
  A map of key-value pairs used to select pods. Only pods with matching labels will be managed by this deployment.

• app: golang-ex
  The label key and value that the selector uses to match pods. In this case, it matches pods labeled app: golang-ex.

• template:
  Describes the pod template for creating replicas. This section defines the specifications of the pods that will be deployed.

• metadata:
  Metadata for the pod template. This often includes labels.

• labels:
  Key-value pairs that will be applied as labels to the pods created from this template.

• app: golang-ex
  A label applied to the pods for identification and selection purposes.

• spec:
  The pod specification, describing the containers, volumes, and other aspects of the pod runtime environment.

• restartPolicy: Always
  Indicates that the pods should always be restarted if they are terminated, except when they are manually stopped.

• serviceAccountName: default
  Specifies the service account under which the pods will run. Here, the default service account is used.

• imagePullSecrets:
  Specifies a list of secrets used to pull private Docker images.

• - name: default-dockercfg-xlv29
  The name of the secret containing Docker credentials, used to pull images from a private registry.

• priority: 0
  Specifies the priority of the pods. A lower value means lower priority.

• schedulerName: default-scheduler
  Specifies the scheduler to be used for placing the pods on nodes. The default Kubernetes scheduler is being used here.

• enableServiceLinks: true
  Determines whether information about services (environment variables) should be automatically injected into pods.

• terminationGracePeriodSeconds: 30
  Specifies the grace period to allow for pod termination. Kubernetes waits for 30 seconds before forcefully terminating the pod.

• preemptionPolicy: PreemptLowerPriority
  Defines the preemption policy for pods, which allows this pod to evict other lower-priority pods if resources are constrained.

• securityContext:
  Defines security settings for the pod, including user permissions and SELinux options.

• seLinuxOptions:
  Configures SELinux options for the pod.

• level: 's0:c26,c5'
  Sets the SELinux level for the pod.

• fsGroup: 1000660000
  Defines a group ID that will be applied to all files that are created by the pod. It allows sharing files between containers in a pod.

• seccompProfile:
  Configures the seccomp profile for the pod, which is a security feature to restrict the system calls a process can make.

• type: RuntimeDefault
  Uses the default seccomp profile provided by the container runtime.

• containers:
  Lists the containers that will run inside the pods created by this deployment.

• - name: golang-ex
  The name of the container. Each container in a pod must have a unique name.

• image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2'
  Specifies the image used for the container. This image is pulled from a private registry and is identified by its SHA256 digest.

• resources: {}
  Resource requests and limits for the container are left empty here, meaning no specific CPU or memory constraints are applied.

• volumeMounts:
  Lists the volumes to be mounted into the container’s filesystem.

• - name: kube-api-access-kmdlt
  Specifies the volume name to be mounted.

• readOnly: true
  Indicates that the volume is mounted as read-only.

• mountPath: /var/run/secrets/kubernetes.io/serviceaccount
  The path in the container where the volume is mounted. This is typically used to provide the service account credentials to the container.

• terminationMessagePath: /dev/termination-log
  Specifies the path where the termination message (logs) of the container is written.

• terminationMessagePolicy: File
  Defines how the termination messages are retrieved. Here, it specifies using a file to retrieve these messages.

• imagePullPolicy: IfNotPresent
  Indicates the container image is pulled only if it is not already present on the node. This optimizes image pulls.

• securityContext:
  Security settings specific to this container.

• capabilities:
  Configures Linux capabilities for the container.

• drop:
  Specifies capabilities to drop from the default set.

• - ALL
  All Linux capabilities are dropped, providing a more secure environment.

• runAsUser: 1000660000
  Specifies the user ID under which the container should run.

• runAsNonRoot: true
  Ensures the container runs as a non-root user, enhancing security.

• allowPrivilegeEscalation: false
  Prevents the container from gaining more privileges than its parent process, improving security.

• serviceAccount: default
  Specifies the service account to be used by the pod.

• volumes:
  Lists the volumes available to the containers in the pod.

• - name: kube-api-access-kmdlt
  Defines a projected volume, which is a collection of various volume sources.

• projected:
  Defines the projected volume type, allowing for multiple sources to be projected into the same directory.

• sources:
  The list of different sources included in the projected volume.

• - serviceAccountToken:
  Defines a volume source containing a service account token.

• expirationSeconds: 3607
  The time in seconds after which the service account token expires.

• path: token
  The path within the projected volume where the token is placed.

• - configMap:
  Defines a volume source coming from a ConfigMap, which is a key-value store used to hold configuration data.

• name: kube-root-ca.crt
  The name of the ConfigMap used as a volume source.

• items:
  Lists specific keys to project from the ConfigMap.

• - key: ca.crt
  The key from the ConfigMap.

• path: ca.crt
  The path within the projected volume where the ConfigMap data is placed.

• - downwardAPI:
  Defines a volume source from the Downward API, which provides metadata about the pod or container.

• items:
  Specifies individual fields to be projected from the Downward API.

• - path: namespace
  The path within the projected volume for this Downward API item.

• fieldRef:
  References a specific field of the pod.

• apiVersion: v1
  Specifies the API version of the field.

• fieldPath: metadata.namespace
  The field path to project. In this case, it projects the namespace of the pod.

68.

- configMap:
Another ConfigMap used as a volume source.

• name: openshift-service-ca.crt
  The name of the ConfigMap providing a certificate.

• items:
  Specifies the particular item from the ConfigMap to use.

• - key: service-ca.crt
  The key in the ConfigMap to use.

• path: service-ca.crt
  The path within the projected volume where the certificate is placed.

• defaultMode: 420
  Sets the default file permissions for files in this volume.

• dnsPolicy: ClusterFirst
  Sets the DNS policy for the pod. ClusterFirst prefers the DNS entries in the cluster.

• tolerations:
  Specifies tolerations for the pods, which allows them to be scheduled on nodes with matching taints.

• - key: node.kubernetes.io/not-ready
  A toleration key indicating the pod can tolerate nodes marked as "not ready".

• operator: Exists
  The operator to match the toleration key. Exists means this toleration matches any value.

• effect: NoExecute
  Indicates the effect of the taint, which in this case prevents execution on the node unless the toleration is set.

• tolerationSeconds: 300
  The duration for which the toleration is valid, in seconds.

• - key: node.kubernetes.io/unreachable
  Another toleration key indicating the pod can tolerate nodes marked as "unreachable".

• operator: Exists
  Matches the key if it exists, regardless of value.

• effect: NoExecute
  The effect, as with the previous toleration, is to prevent execution on the node unless the toleration is applied.

• tolerationSeconds: 300
  The duration for which this toleration is valid, allowing the pod to remain scheduled on unreachable nodes for up to 300 seconds.

This YAML file defines a Kubernetes Deployment for an application named "golang-ex" within the "myapp-project" namespace. It specifies detailed configuration for the deployment, including three replicas, security contexts, image pulling policies, and various tolerations and volumes to ensure the pods operate securely and with the correct configurations.

replicas was the second step

At least evaluate for a health check is another deployment

Error at deployment

To add a health check (readiness and liveness probe) to your Kubernetes Deployment YAML for the golang-ex application, you need to specify the livenessProbe and readinessProbe settings under the container spec. Below is your modified YAML with these health checks added:

kind: Deployment
apiVersion: apps/v1
metadata:
annotations:
deployment.kubernetes.io/revision: '2'
image.openshift.io/triggers: '[{"from":{"kind":"ImageStreamTag","name":"golang-ex:latest"},"fieldPath":"spec.template.spec.containers[?(@.name==\"golang-ex\")].image"}]'
openshift.io/generated-by: OpenShiftNewApp
resourceVersion: '234328'
name: golang-ex
uid: 135f03f6-ba79-4cfe-98b6-c000b5705583
creationTimestamp: '2024-08-21T12:24:34Z'
generation: 2
managedFields:
- manager: oc.exe
operation: Update
apiVersion: apps/v1
time: '2024-08-21T12:24:34Z'
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
.: {}
'f:image.openshift.io/triggers': {}
'f:openshift.io/generated-by': {}
'f:labels':
.: {}
'f:app': {}
'f:app.kubernetes.io/component': {}
'f:app.kubernetes.io/instance': {}
'f:spec':
'f:progressDeadlineSeconds': {}
'f:replicas': {}
'f:revisionHistoryLimit': {}
'f:selector': {}
'f:strategy':
'f:rollingUpdate':
.: {}
'f:maxSurge': {}
'f:maxUnavailable': {}
'f:type': {}
'f:template':
'f:metadata':
'f:annotations':
.: {}
'f:openshift.io/generated-by': {}
'f:labels':
.: {}
'f:deployment': {}
'f:spec':
'f:containers':
'k:{"name":"golang-ex"}':
.: {}
'f:imagePullPolicy': {}
'f:name': {}
'f:resources': {}
'f:terminationMessagePath': {}
'f:terminationMessagePolicy': {}
'f:dnsPolicy': {}
'f:restartPolicy': {}
'f:schedulerName': {}
'f:securityContext': {}
'f:terminationGracePeriodSeconds': {}
- manager: openshift-controller-manager
operation: Update
apiVersion: apps/v1
time: '2024-08-21T12:25:05Z'
fieldsType: FieldsV1
fieldsV1:
'f:spec':
'f:template':
'f:spec':
'f:containers':
'k:{"name":"golang-ex"}':
'f:image': {}
- manager: kube-controller-manager
operation: Update
apiVersion: apps/v1
time: '2024-09-02T11:27:01Z'
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
'f:deployment.kubernetes.io/revision': {}
'f:status':
'f:availableReplicas': {}
'f:conditions':
.: {}
'k:{"type":"Available"}':
.: {}
'f:lastTransitionTime': {}
'f:lastUpdateTime': {}
'f:message': {}
'f:reason': {}
'f:status': {}
'f:type': {}
'k:{"type":"Progressing"}':
.: {}
'f:lastTransitionTime': {}
'f:lastUpdateTime': {}
'f:message': {}
'f:reason': {}
'f:status': {}
'f:type': {}
'f:observedGeneration': {}
'f:readyReplicas': {}
'f:replicas': {}
'f:updatedReplicas': {}
subresource: status
namespace: myapp-project
labels:
app: golang-ex
app.kubernetes.io/component: golang-ex
app.kubernetes.io/instance: golang-ex
spec:
replicas: 1
selector:
matchLabels:
deployment: golang-ex
template:
metadata:
creationTimestamp: null
labels:
deployment: golang-ex
annotations:
openshift.io/generated-by: OpenShiftNewApp
spec:
containers:
- name: golang-ex
image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2'
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
readinessProbe:
httpGet:
path: /readiness
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
successThreshold: 1
restartPolicy: Always
terminationGracePeriodSeconds: 30
dnsPolicy: ClusterFirst
securityContext: {}
schedulerName: default-scheduler
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
revisionHistoryLimit: 10
progressDeadlineSeconds: 600
status:
observedGeneration: 2
replicas: 1
updatedReplicas: 1
readyReplicas: 1
availableReplicas: 1
conditions:
- type: Progressing
status: 'True'
lastUpdateTime: '2024-08-21T12:25:16Z'
lastTransitionTime: '2024-08-21T12:24:34Z'
reason: NewReplicaSetAvailable
message: ReplicaSet "golang-ex-774567f659" has successfully progressed.
- type: Available
status: 'True'
lastUpdateTime: '2024-09-02T11:27:01Z'
lastTransitionTime: '2024-09-02T11:27:01Z'
reason: MinimumReplicasAvailable
message: Deployment has minimum availability.

Key Changes:

• Liveness Probe:

• Checks if the application is alive and should be restarted if it is not responding.

• Configured to check the /healthz endpoint on port 8080.

• Begins checking 10 seconds after the container starts (initialDelaySeconds: 10), with checks every 10 seconds (periodSeconds: 10).

• A 5-second timeout is set for each check (timeoutSeconds: 5).

• Readiness Probe:

• Determines if the application is ready to serve traffic.

• Configured to check the /readiness endpoint on port 8080.

• Begins checking 5 seconds after the container starts (initialDelaySeconds: 5), with checks every 5 seconds (periodSeconds: 5).

• A 3-second timeout is set for each check (timeoutSeconds: 3).

Ensure that your application properly handles requests to the /healthz and /readiness endpoints. Adjust paths, ports, and timings as necessary to fit your specific application's requirements.

You're right. When defining a Kubernetes Deployment manifest for a new resource, the resourceVersion field should not be set. The resourceVersion field is managed by Kubernetes and is used for concurrency control to ensure the object being updated is consistent with the current version in the cluster.

Here is the modified YAML for your golang-ex Deployment without the resourceVersion field:

kind: Deployment
apiVersion: apps/v1
metadata:
annotations:
deployment.kubernetes.io/revision: '2'
image.openshift.io/triggers: '[{"from":{"kind":"ImageStreamTag","name":"golang-ex:latest"},"fieldPath":"spec.template.spec.containers[?(@.name==\"golang-ex\")].image"}]'
openshift.io/generated-by: OpenShiftNewApp
name: golang-ex
uid: 135f03f6-ba79-4cfe-98b6-c000b5705583
creationTimestamp: '2024-08-21T12:24:34Z'
generation: 2
managedFields:
- manager: oc.exe
operation: Update
apiVersion: apps/v1
time: '2024-08-21T12:24:34Z'
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
.: {}
'f:image.openshift.io/triggers': {}
'f:openshift.io/generated-by': {}
'f:labels':
.: {}
'f:app': {}
'f:app.kubernetes.io/component': {}
'f:app.kubernetes.io/instance': {}
'f:spec':
'f:progressDeadlineSeconds': {}
'f:replicas': {}
'f:revisionHistoryLimit': {}
'f:selector': {}
'f:strategy':
'f:rollingUpdate':
.: {}
'f:maxSurge': {}
'f:maxUnavailable': {}
'f:type': {}
'f:template':
'f:metadata':
'f:annotations':
.: {}
'f:openshift.io/generated-by': {}
'f:labels':
.: {}
'f:deployment': {}
'f:spec':
'f:containers':
'k:{"name":"golang-ex"}':
.: {}
'f:imagePullPolicy': {}
'f:name': {}
'f:resources': {}
'f:terminationMessagePath': {}
'f:terminationMessagePolicy': {}
'f:dnsPolicy': {}
'f:restartPolicy': {}
'f:schedulerName': {}
'f:securityContext': {}
'f:terminationGracePeriodSeconds': {}
- manager: openshift-controller-manager
operation: Update
apiVersion: apps/v1
time: '2024-08-21T12:25:05Z'
fieldsType: FieldsV1
fieldsV1:
'f:spec':
'f:template':
'f:spec':
'f:containers':
'k:{"name":"golang-ex"}':
'f:image': {}
- manager: kube-controller-manager
operation: Update
apiVersion: apps/v1
time: '2024-09-02T11:27:01Z'
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
'f:deployment.kubernetes.io/revision': {}
'f:status':
'f:availableReplicas': {}
'f:conditions':
.: {}
'k:{"type":"Available"}':
.: {}
'f:lastTransitionTime': {}
'f:lastUpdateTime': {}
'f:message': {}
'f:reason': {}
'f:status': {}
'f:type': {}
'k:{"type":"Progressing"}':
.: {}
'f:lastTransitionTime': {}
'f:lastUpdateTime': {}
'f:message': {}
'f:reason': {}
'f:status': {}
'f:type': {}
'f:observedGeneration': {}
'f:readyReplicas': {}
'f:replicas': {}
'f:updatedReplicas': {}
subresource: status
namespace: myapp-project
labels:
app: golang-ex
app.kubernetes.io/component: golang-ex
app.kubernetes.io/instance: golang-ex
spec:
replicas: 1
selector:
matchLabels:
deployment: golang-ex
template:
metadata:
creationTimestamp: null
labels:
deployment: golang-ex
annotations:
openshift.io/generated-by: OpenShiftNewApp
spec:
containers:
- name: golang-ex
image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2'
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
readinessProbe:
httpGet:
path: /readiness
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
successThreshold: 1
restartPolicy: Always
terminationGracePeriodSeconds: 30
dnsPolicy: ClusterFirst
securityContext: {}
schedulerName: default-scheduler
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
revisionHistoryLimit: 10
progressDeadlineSeconds: 600
status:
observedGeneration: 2
replicas: 1
updatedReplicas: 1
readyReplicas: 1
availableReplicas: 1
conditions:
- type: Progressing
status: 'True'
lastUpdateTime: '2024-08-21T12:25:16Z'
lastTransitionTime: '2024-08-21T12:24:34Z'
reason: NewReplicaSetAvailable
message: ReplicaSet "golang-ex-774567f659" has successfully progressed.
- type: Available
status: 'True'
lastUpdateTime: '2024-09-02T11:27:01Z'
lastTransitionTime: '2024-09-02T11:27:01Z'
reason: MinimumReplicasAvailable
message: Deployment has minimum availability.

Key Changes:

• Removed the resourceVersion field under the metadata section, as it should not be set when creating a new resource.

Now, this YAML is ready to be used to create a new deployment without issues related to resourceVersion. Make sure the application handles requests to the specified endpoints for the liveness and readiness probes. Adjust the paths, ports, and timings as necessary to fit your specific application's requirements.

deployments.apps "golang-ex" already exists

If the Deployment named golang-ex already exists in your Kubernetes cluster and you want to update it (for example, to add the health checks), you should use the kubectl apply or kubectl patch command to modify the existing deployment rather than creating a new one.

Here's how you can update the existing Deployment:

• Edit the Deployment Manifest:
  Remove the resourceVersion, uid, creationTimestamp, and managedFields fields from your YAML file because these fields are automatically managed by Kubernetes and shouldn't be specified in the update. Here's an updated YAML for the Deployment:

kind: Deployment
apiVersion: apps/v1
metadata:
name: golang-ex
namespace: myapp-project
labels:
app: golang-ex
app.kubernetes.io/component: golang-ex
app.kubernetes.io/instance: golang-ex
annotations:
deployment.kubernetes.io/revision: '2'
image.openshift.io/triggers: '[{"from":{"kind":"ImageStreamTag","name":"golang-ex:latest"},"fieldPath":"spec.template.spec.containers[?(@.name==\"golang-ex\")].image"}]'
openshift.io/generated-by: OpenShiftNewApp
spec:
replicas: 1
selector:
matchLabels:
deployment: golang-ex
template:
metadata:
labels:
deployment: golang-ex
annotations:
openshift.io/generated-by: OpenShiftNewApp
spec:
containers:
- name: golang-ex
image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2'
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 10
periodSeconds: 10
timeoutSeconds: 5
failureThreshold: 3
successThreshold: 1
readinessProbe:
httpGet:
path: /readiness
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 3
successThreshold: 1
restartPolicy: Always
terminationGracePeriodSeconds: 30
dnsPolicy: ClusterFirst
securityContext: {}
schedulerName: default-scheduler
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 25%
revisionHistoryLimit: 10
progressDeadlineSeconds: 600

• Apply the Changes:
  Use the kubectl apply command to update the existing deployment with the new configuration.

kubectl apply -f updated-deployment.yaml

Make sure to replace updated-deployment.yaml with the filename where you've saved the modified YAML configuration.

• Check the Deployment Status:
  After applying the changes, you can check the status of your deployment to ensure that it is updated correctly and the pods are running with the new configuration.

kubectl get deployment golang-ex -n myapp-project
kubectl describe deployment golang-ex -n myapp-project
kubectl get pods -n myapp-project

By following these steps, you should be able to update the existing Deployment without any issues related to trying to create a resource that already exists.

Go in with a different name

404 at the start

new deployment

**With health checks i can see there are requests coming in **

ask if you cant find

In the provided YAML for the golang-ex-new Deployment, the health checks (liveness and readiness probes) are defined under the container specification for the golang-ex container. Here's where they are located in the YAML:

Location of Health Checks in the YAML:

spec:
template:
spec:
containers:
- name: golang-ex
image: 'image-registry.openshift-image-registry.svc:5000/myapp-project/golang-ex@sha256:5285855b739c8613fa614a9ac991b7e70164bb4db819b0f327a42937a3b9dac2'
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
imagePullPolicy: IfNotPresent
livenessProbe: # Liveness probe definition
httpGet:
path: /healthz # Endpoint to check for liveness
port: 8080
initialDelaySeconds: 10 # Delay before the probe starts
periodSeconds: 10 # Frequency of the probe
timeoutSeconds: 5 # Timeout for the probe response
failureThreshold: 3 # Number of failures before marking as failed
successThreshold: 1 # Number of successes before marking as successful
readinessProbe: # Readiness probe definition
httpGet:
path: /readiness # Endpoint to check for readiness
port: 8080
initialDelaySeconds: 5 # Delay before the probe starts
periodSeconds: 5 # Frequency of the probe
timeoutSeconds: 3 # Timeout for the probe response
failureThreshold: 3 # Number of failures before marking as not ready
successThreshold: 1 # Number of successes before marking as ready

Explanation of Health Checks:

• Liveness Probe (livenessProbe):

• Purpose: Checks if the application is still running. If the probe fails, Kubernetes will restart the container.

• Configuration:

httpGet: Makes an HTTP GET request to the /healthz endpoint on port 8080.

• initialDelaySeconds: Waits 10 seconds after the container starts before performing the first check.

• periodSeconds: Checks every 10 seconds.

• timeoutSeconds: Waits up to 5 seconds for a response before timing out.

• failureThreshold: If the probe fails 3 times consecutively, the container is considered unhealthy and will be restarted.

• successThreshold: The number of consecutive successes required to mark the container as healthy (only 1 is needed here).

• Readiness Probe (readinessProbe):

• Purpose: Checks if the application is ready to accept traffic. If the probe fails, the container is marked as not ready, and traffic is not routed to it.

• Configuration:

httpGet: Makes an HTTP GET request to the /readiness endpoint on port 8080.

• initialDelaySeconds: Waits 5 seconds after the container starts before performing the first check.

• periodSeconds: Checks every 5 seconds.

• timeoutSeconds: Waits up to 3 seconds for a response before timing out.

• failureThreshold: If the probe fails 3 times consecutively, the container is marked as not ready.

• successThreshold: The number of consecutive successes required to mark the container as ready (only 1 is needed here).

What to Adjust if Needed:

• Path: Ensure that the /healthz and /readiness endpoints are correctly implemented in your application. Adjust these paths as needed.

• Port: Make sure port 8080 is the correct port where your application is running. Update it if necessary.

• Timings: Adjust initialDelaySeconds, periodSeconds, timeoutSeconds, failureThreshold, and successThreshold based on your application’s startup and runtime behavior.

By defining these probes, Kubernetes can automatically manage the availability and readiness of your application, improving its resilience and reliability.

To spot and configure a liveness probe in the OpenShift Web Console, follow these steps:

1. Access the OpenShift Web Console

• Log in to your OpenShift Web Console using your credentials.

• Navigate to the project (namespace) where your deployment (e.g., golang-ex-new) is located. You can switch projects from the top-left corner dropdown.

2. Navigate to the Workloads Section

• In the left-hand navigation pane, click on "Workloads".

• Click on "Deployments" to see the list of deployments in the selected project.

3. Find and Select Your Deployment

• Find your deployment (e.g., golang-ex-new) in the list of deployments.

• Click on the deployment name to open its details page.

4. View or Edit the Liveness Probe

• Once you are on the deployment's details page, click on the "Actions" dropdown menu at the top right corner.

• Select "Edit Health Checks" from the dropdown menu. This option allows you to view and configure the liveness and readiness probes for your containers. Alternatively, you might directly see an option for "Health Checks" or "Edit Health Checks" in the navigation tabs of the deployment's details page, depending on the version of OpenShift you are using.

5. Spot the Liveness Probe Configuration

• In the Health Checks configuration window:

• You will see sections for Liveness Probe, Readiness Probe, and possibly Startup Probe.

• The Liveness Probe section displays the current configuration if it is already set. Look for fields such as:

Type (HTTP, Command, or TCP)

• HTTP GET Path (e.g., /healthz)

• Port (e.g., 8080)

• Initial Delay (seconds)

• Timeout (seconds)

• Period (seconds)

• Failure Threshold

6. Edit the Liveness Probe

• To edit the liveness probe:

• Adjust the type (HTTP GET, Command, or TCP), path, port, initial delay, timeout, period, and failure threshold according to your requirements.

• Click "Save" or "Update" to apply the changes.

7. Apply and Monitor Changes

• After updating the liveness probe, OpenShift will automatically restart the deployment pods to apply the new settings.

• You can monitor the status of your pods and the effects of the new liveness probe settings by going back to the "Pods" section under "Workloads" and checking their status and logs.

Additional Tips:

• Logs and Events: If you encounter issues, you can check the Events tab on the deployment page or view the logs of individual pods to troubleshoot the behavior of the liveness probe.

• Command Line: Alternatively, you can use the OpenShift CLI (oc) to check the liveness probe configuration by describing the deployment:

oc describe deployment golang-ex-new -n myapp-project

Look for the Liveness section under Containers to see the current settings.

By following these steps, you can easily spot, view, and modify the liveness probe configuration for your deployment in the OpenShift Web Console.

remove is the way to take it down

Add health checks is the way to go

Converge and Summary Repo

https://github.com/rifaterdemsahin/openshifthealthchecks/blob/main/README.md

Conclusion

Disabling health check promotion in OpenShift is a useful strategy for managing deployments with specific requirements, such as starting with zero replicas or bypassing automatic promotions temporarily. Always remember to re-enable these settings post-deployment to maintain a healthy and resilient production environment. By understanding when and how to adjust these settings, you can better control your deployment processes and ensure smoother operations within your OpenShift environments.

🔗 Connect with me:

• 💼 LinkedIn: https://www.linkedin.com/in/rifaterdemsahin/

• 🐦 Twitter: https://x.com/rifaterdemsahin

• 🎥 YouTube: https://www.youtube.com/@RifatErdemSahin

• 💻 GitHub: https://github.com/rifaterdemsahin

Imported from rifaterdemsahin.com · 2024