51–60 of 65 posts
Is there a clean way to share an emptyDir between sidecar(s) and main container(s)? Looking at the logging usecase and want to be able to add a log shipper sidecar to a pod with ephemeral storage.
You wouldn’t need a sidecar-per-pod this way either.
Earlier quoted context omitted.
As a consumer, ECS + Fargate is my happy path. I appreciate the lack of complexity. Thanks.
Ditto. ECS/Fargate has always been the easiest, most flexible, most useful containerization solution. It's the one AWS service with the most value to containerized services, and the least appreciated.
From what i've head they've made a great many quality of life improvements but as is often the case it can be hard to regain share when you've already lost people.
While this is a very welcome improvement in terms of functionality, I can't help by feel that the re-use of "restartPolicy" to mean something similar, but different, when used in a different context, is a very poor decision. Kubernetes already has an issue with having a (perceived) high barrier to entry, and I'm not sure that "restartPolicy on a container means this, unless isn't used in this list of containers, in w…
The only difference today between init containers and regular containers is:
a) init containers have an implicit default restart policy of OnFailure, and regular containers inherit the pods restartPolicy
b) init containers are serial, regular containers are parallel
We are leaving room for the possibility that init containers can fail the pod, and be parallelized, as well as regular containers having unique restartPolicies. Both of those would allow more control for workflow / job engines to break apart monolith containers and get better isolation.
The key design point was that “sidecars aren’t special containers” - because we want to leave room for future growth.
On the one hand, great. The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It's great about defining pieces of state, but managing blocks of state & multiple things at once is left almost entirely to external tools. The ability to compose &sequence multiple containers feels like a very specific example of a much broader general capability. There's bed…
Yeah I work on the team that builds Amazon Elastic Container Service so I can't help but compare this implementation with how we solved this same problem in ECS. Inside of an ECS task you can add multiple containers and on each container you can specify two fields: `dependsOn` and `essential`. ECS automatically manages container startup order to respect the dependencies you have specified, and on shutdown it tears th…
dependsOn was proposed during the kep review but deferred. But because init containers and regular containers share the same behavior and shape, and differ only on container restart policy, we are taking a step towards “a tree of container node” without breaking forward or backward compatibility.
Given the success of mapping workloads to k8s, the original design goal was to not take on that complexity originally, and it’s good to see others making the case for bringing that flexibility back in.
In case anyone else was looking for a clear, concise summary of the new feature: "The new feature gate "SidecarContainers" is now available. This feature introduces sidecar containers, a new type of init container that starts before other containers but remains running for the full duration of the pod's lifecycle and will not block pod termination."
Earlier quoted context omitted.
Absolutely, no shortage of things atop. Helm is probably the most well used composition tool. It seems unideal to me to forever bunt on this topic, leaving it out of core forever. Especially when we are slowly adding im very specialized composition orchestration tools in core.
Requiring the user to write their own operators to manage state using the kubernetes api is very much a feature and not something which is missing.
But! The one thing that custom orchestrators can’t do is easily get the benefit of kubelet isolation of containers and resource management. Part of slowly moving down this path is to allow those orchestrators to get isolation from the node without having to reimplement that isolation. But it will take some time.
Earlier quoted context omitted.
Yeah I work on the team that builds Amazon Elastic Container Service so I can't help but compare this implementation with how we solved this same problem in ECS. Inside of an ECS task you can add multiple containers and on each container you can specify two fields: `dependsOn` and `essential`. ECS automatically manages container startup order to respect the dependencies you have specified, and on shutdown it tears th…
As a consumer, ECS + Fargate is my happy path. I appreciate the lack of complexity. Thanks.
If image caching becomes a reality with Fargate I can't imagine a need to ever use anything else
Earlier quoted context omitted.
Requiring the user to write their own operators to manage state using the kubernetes api is very much a feature and not something which is missing.
Agreed that is a feature and not a bug. But! The one thing that custom orchestrators can’t do is easily get the benefit of kubelet isolation of containers and resource management. Part of slowly moving down this path is to allow those orchestrators to get isolation from the node without having to reimplement that isolation. But it will take some time.
On the one hand, great. The other hand, one of the main criticisms of Kubernetes is that it has no composition or orchestration capabilities. It's great about defining pieces of state, but managing blocks of state & multiple things at once is left almost entirely to external tools. The ability to compose &sequence multiple containers feels like a very specific example of a much broader general capability. There's bed…
Orchestration of k8s wouldn't be necessary if they had made K8s' operation immutable. As it stands now you just throw some random YAML at it and hope for the best. When that stops working, you can't just revert back to the old working version, you have to start throwing more crap at it and running various operations to "fix" the state. So you end up with all these tools that are effectively configuration management t…
When I first learned about the sidecar pattern I thought it was great. I am not sure about it anymore. Most of it could be propagated to custom images or layers at the boundary. To me this feels a bit sketchy. Too have containers that kinda is part of the mesh but then does not share the same lifecycle as the mesh.
If you create a custom image you would need to create a complex health endpoint that is essentially only considered healthy if all the components baked into your image are considered healthy. This gets harder when you are not the author of the sidecar process on which you rely. With a single image it would be easier to run into a situation where the sidecar process (baked into your image) is in an unhealthy state but…