Deployment

133

In Kubernetes, a Deployment is responsible for creating and updating instances of your application. A Deployment provides declarative updates for Pods and ReplicaSets.

Stuff you wanna know:

    1. The Deployment instructs Kubernetes how to create and update instances of your application.
    2. You describe a desired state in a Deployment, and the Deployment Controller changes the actual state to the desired state at a controlled rate.
    3. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.
    4. You can run an application by creating a Kubernetes Deployment object, and you can describe a Deployment in a YAML file.
    5.  You can update a Deployment by applying a new YAML file.
    6. You can increase the number of Pods in your Deployment by applying a new YAML file.
    7. Once you’ve created a Deployment, the Kubernetes control plane schedules the application instances included in that Deployment to run on individual Nodes in the cluster.
    8. Once the application instances are created, a Kubernetes Deployment Controller continuously monitors those instances.
    9. Deployment is a top-level resource in the Kubernetes REST API.
    10. Self-healing mechanism — If the Node hosting an instance goes down or is deleted, the Deployment controller replaces the instance with an instance on another Node in the cluster.
    11. By both creating your application instances and keeping them running across Nodes, Kubernetes Deployments provide a fundamentally different approach to application management. (In a pre-orchestration world, installation scripts would often be used to start applications, but they did not allow recovery from machine failure.)
    12. You can create and manage a Deployment by using the Kubernetes command line interface, Kubectl.
    13. When you create a Deployment, you’ll need to specify the container image for your application and the number of replicas that you want to run. You can change this information later by updating your Deployment.
    14. When you update a Deployment, or plan to, you can pause rollouts for that Deployment before you trigger one or more updates. When you’re ready to apply those changes, you resume rollouts for the Deployment. (This approach allows you to apply multiple fixes in between pausing and resuming without triggering unnecessary rollouts.)
    15. A Deployment enters various states during its lifecycle. It can be progressing while rolling out a new ReplicaSet, it can be complete, or it can fail to progress.
    16. One way you can detect a failed deployment is to specify a deadline parameter in your Deployment spec: (.spec.progressDeadlineSeconds). .spec.progressDeadlineSeconds denotes the number of seconds the Deployment controller waits before indicating (in the Deployment status) that the Deployment progress has stalled.
    17. Kubernetes takes no action on a stalled Deployment other than to report a status condition with reason: ProgressDeadlineExceeded.
    18. You may experience transient errors with your Deployments, either due to a low timeout that you have set or due to any other kind of error that can be treated as transient. For example, insufficient quota.
    19. All actions that apply to a complete Deployment also apply to a failed Deployment. You can scale it up/down, roll back to a previous revision, or even pause it if you need to apply multiple tweaks in the Deployment Pod template.
    20. If you want to roll out releases to a subset of users or servers using the Deployment, you can create multiple Deployments, one for each release, following the canary pattern.
    21. The Deployment updates Pods in a rolling update fashion when .spec.strategy.type==RollingUpdate. You can specify maxUnavailable and maxSurge to control the rolling update process.
    22. A Deployment’s revision history is stored in the ReplicaSets it controls.
    23. If you upgrade a Deployment, all Pods of the old revision will be terminated immediately. Successful removal is awaited before any Pod of the new revision is created.
    24. If you manually delete a Pod, the lifecycle is controlled by the ReplicaSet and the replacement will be created immediately (even if the old Pod is still in a Terminating state).

More stuff: