oc-scheduler/helm
2024-09-12 14:37:24 +02:00
..
templates feat: Add oc-scheduler component to Helm chart 2024-09-12 14:37:24 +02:00
Chart.yaml feat: Add oc-scheduler component to Helm chart 2024-09-12 14:37:24 +02:00
README.md feat: Add oc-scheduler component to Helm chart 2024-09-12 14:37:24 +02:00
values.yaml feat: Add oc-scheduler component to Helm chart 2024-09-12 14:37:24 +02:00

README.md - oc-scheduler Helm Chart

This document describes the different tags found in the values.yml file used in the Helm chart for the oc-scheduler component.

Tags in the values.yml file

replicaCount

  • Description: Defines the number of replicas for the deployment. A replica represents an instance of the application that will be deployed.
  • Example: 1 means a single instance of the oc-scheduler service will be deployed.

image.repository

  • Description: Specifies the URL of the Docker image registry where the oc-scheduler component image is stored.
  • Example: registry.dev.svc.cluster.local:5000/oc-scheduler refers to a local registry hosted within the cluster.local network.

image.tag

  • Description: Indicates the tag of the Docker image to use. Typically, this could be a specific version or latest to always pull the latest version.
  • Example: latest means the most recent version of the image will be used.

image.pullPolicy

  • Description: Defines the image pull policy. The possible options are:
    • Always: Always pull the image.
    • IfNotPresent: Pull the image only if it is not already present on the node.
    • Never: Never pull the image.
  • Example: IfNotPresent means the image will only be pulled if it is not already present on the node.

env.mongoDatabase

  • Description: Defines the name of the MongoDB database the application will connect to.
  • Example: DC_myDC refers to the MongoDB database used by the application.

env.mongoUrl

  • Description: Specifies the connection URL for MongoDB used by the application.
  • Example: mongodb://toto:27017 indicates that the application will connect to the MongoDB instance hosted at toto on port 27017.

service.type

  • Description: Defines the type of Kubernetes service. Possible types include:
    • ClusterIP: The service is only accessible within the cluster.
    • NodePort: The service is accessible via a specific port on all cluster nodes.
    • LoadBalancer: The service is exposed via an external Load Balancer.
  • Example: ClusterIP means the service will only be accessible within the Kubernetes cluster.

service.port

  • Description: Specifies the port on which the service will be exposed within the cluster.
  • Example: 8090 means the service will be accessible on port 8090.

service.targetPort

  • Description: Defines the port on which the application listens inside the container.
  • Example: 8080 means the application listens on port 8080 within the container.

resources.limits.cpu

  • Description: Specifies the maximum amount of CPU (in millicores) allocated to the container.
  • Example: 500m means the container can use up to 0.5 CPU (or 50% of a full CPU core).

resources.limits.memory

  • Description: Specifies the maximum amount of memory (in MiB) allocated to the container.
  • Example: 512Mi means the container can use up to 512 MiB of memory.

resources.requests.cpu

  • Description: Defines the guaranteed amount of CPU (in millicores) for the container. Kubernetes will ensure this amount is always available.
  • Example: 250m means the container will have at least 0.25 CPU (or 25% of a full CPU core).

resources.requests.memory

  • Description: Defines the guaranteed amount of memory (in MiB) for the container. Kubernetes will reserve this memory for the container.
  • Example: 256Mi means the container will have at least 256 MiB of memory.

Conclusion

This values.yml file allows configuring the deployment settings for the oc-scheduler component. Each tag plays a specific role in defining the Docker image, service configuration, and resource allocation for the container within the Kubernetes cluster.