We'll need kubectl to do and verify deployments of production images in the deployment pipeline
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | None | T170453 FY2017/18 Program 6: Streamlined Service delivery | |||
| Invalid | None | T170480 FY2017/18 Program 6 - Outcome 2: Developers are able to develop and test their applications through a unified pipeline towards production deployment. | |||
| Invalid | None | T170481 FY2017/18 Program 6 - Outcome 2 - Objective 2: Set up a continuous integration and deployment pipeline | |||
| Resolved | None | T157469 Mathoid CI Container Build | |||
| Resolved | • dduvall | T183165 Verify functionality of the 'production' image in the context of an isolated k8s deployment | |||
| Resolved | • dduvall | T188933 install kubectl on integration agents |
Event Timeline
Comment Actions
I think @akosiaris told me once we should aim at not using kubectl but instead rely on the API. But maybe I got confused. Surely for prototyping that is good enough, but we should keep in mind what will be used long term when we reach production status.
Comment Actions
Yes. kubectl is a great and essential debugging tool, but it should not be used in day to day work. To paraphrease Kelsey Hightower as good as I can remember, kubectl is the equivalent of ssh. When you end up using ssh to get stuff done, consider it a bug, same goes for kubectl.
but instead rely on the API.
Or wrap around some other tool that talks to the API. helm is the status quo currently. And its even supports plugins so we can add functionality to it. And it supports both the do deployments and verify deployments parts of this task.
I am not against having it installed on the integration hosts, on the contrary, but keep the above in mind and act accordingly.