Commits on Feb 8, 2022

1. Add default k8s resources for init containers …

   This commit adds resource requests and limits for CPU and memory to Tekton-controlled init containers.
   Prior to this commit, if a ResourceQuota was defined in a namespace, Tekton could not be used in that namespace
   because not all containers in the generated pods had CPU and memory requests and limits.
   
   This commit does not affect Tekton's handling of LimitRange. Tekton will continue to transform container
   resource requests and limits to fit LimitRanges.
   
   * What do these init containers do? *
   - "place-tools" runs the entrypoint binary and writes it into each step container
   - "place-scripts" encodes each step's script and writes it to the container that will run it.
   We do not limit the size of scripts.
   - "step-init" initializes /tekton/steps with one file per step
   - "working-dir-initializer" creates a working dir for each step that needs it
   
   * Where do these resource requirements come from? *
   - The latest entrypoint binary is about 80MB. Previous builds were closer to 40-50MB.
   - CPU requirements, and memory requirements for non-entrypoint containers, are guesses with some simple local experimentation.
   (It's challenging to get metrics for resource usage of Tekton init containers, and we'd need
   some sort of performance or load tests to really get a good estimate.)
   
   * Side effects *
   - Tekton pods now have "burstable" quality of service by default instead of "best effort", meaning they will
   be more likely to be scheduled and less likely to be evicted.
   It's no longer possible to create a Tekton pod with "best effort" quality of service.
   
   * Drawbacks *
   - If we update the entrypoint code and the binary changes size, the resource requirements will need to be adjusted.
   Because Tekton releases include building the entrypoint binary, this could break a release and we'd have to backport a fix.
   - If a pod is OOMkilled due to exceeding resource requirements, the user will not be able to work around this problem.
   This can be mitigated by setting the init container's resource requirements to higher than what it likely needs.
   
   * Alternatives *
   - We could apply resource requirements from a Task's StepTemplate to init containers. However, the StepTemplate
   is meant to be used for Steps, which likely have higher resource requirements than Tekton's init containers,
   and this would require users to understand what Tekton's init containers do.
   - We could try to set resource requirements dynamically based on the number of Steps, the size of scripts, or other parameters.
   - We could apply resource requirements to init containers only when ResourceQuotas are present in the namespace.
   
   * Future work *
   - Combine Tekton init containers into one init container
   
   * References *
   - Resource quota docs: https://kubernetes.io/docs/concepts/policy/resource-quotas/
   - Pod quality of service docs: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/
   - Tekton entrypoint images: https://pantheon.corp.google.com/gcr/images/tekton-releases/us/github.com/tektoncd/pipeline/cmd/entrypoint?project=tekton-releases

   

   lbernick committed Feb 8, 2022
   Configuration menu

   • View commit details
   • Copy full SHA for 050ff18
   • Browse repository at this point

   Copy the full SHA

   050ff18 View commit details

   Browse the repository at this point in the history