I'm going to come back with another reply mostly because of the first sentence "I'm not sure why you'd want to work directly on containers or k8s pods" - it's one I hear a lot (particularly in the PHP world) and it's a very interesting thing.
About k8s pods, unless you happen to use PHP for microservices (particularly if you're using roadrunner instead of fpm or one of the newer microservice oriented frameworks like symlex or lumen) you probably don't need k8s generally (a regular monolith application is cumbersome to setup with k8s and won't perform nowhere nearly as well). But if, like me, you do then you will eventually work for a system that's big enough (my previous project had ~ 100 microservices spread across 4 languages) so that you can't run even the close dependencies locally. In that case what you would do is either run a local container + a tool called "telepresence" to have your local container effectively replace a container in a pod in a remote cluster or, alternatively, you would just run a remote pod alone. You would continue editing your code, running your xdebug, etc in Vscode with everything taking effect both locally and remotely. Technically that covers both cases.
Just locally, however, there's also the case when it's a bit of a headache to reliably install/build php modules locally (eg: on Mac and Windows you can't build/get all versions of php's amqp extension if you hope to keep your OS updated, same with redis to a certain extent). So, just run a Docker container. Same with the (granted, edge case) when you'd need to switch multiple PHP versions on the fly or you simply want a reliable environment tat closely mimics a stable remote (eg: I want to have modules x/y available but not z - will you uninstall and reinstall z whenever needed?)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm going to come back with another reply mostly because of the first sentence "I'm not sure why you'd want to work directly on containers or k8s pods" - it's one I hear a lot (particularly in the PHP world) and it's a very interesting thing.
About k8s pods, unless you happen to use PHP for microservices (particularly if you're using roadrunner instead of fpm or one of the newer microservice oriented frameworks like symlex or lumen) you probably don't need k8s generally (a regular monolith application is cumbersome to setup with k8s and won't perform nowhere nearly as well). But if, like me, you do then you will eventually work for a system that's big enough (my previous project had ~ 100 microservices spread across 4 languages) so that you can't run even the close dependencies locally. In that case what you would do is either run a local container + a tool called "telepresence" to have your local container effectively replace a container in a pod in a remote cluster or, alternatively, you would just run a remote pod alone. You would continue editing your code, running your xdebug, etc in Vscode with everything taking effect both locally and remotely. Technically that covers both cases.
Just locally, however, there's also the case when it's a bit of a headache to reliably install/build php modules locally (eg: on Mac and Windows you can't build/get all versions of php's amqp extension if you hope to keep your OS updated, same with redis to a certain extent). So, just run a Docker container. Same with the (granted, edge case) when you'd need to switch multiple PHP versions on the fly or you simply want a reliable environment tat closely mimics a stable remote (eg: I want to have modules x/y available but not z - will you uninstall and reinstall z whenever needed?)