huh? What does that mean? Maybe that means the environment is broken, not the software you want to use/work on.
> For instance, why should a developer even know what an ingress is and that it might be something he needs?
Then probably that dev shouldn't work with k8s. At all.
If the dev wants/needs a hello world on a domain/IP, then they need a web hosting service provider. (ghost.org) Or a PaaS (Heroku), or they can spin up a VM on DigitalOcean and follow any of the thousand Ubuntu Nginx Website Hosting tutorials on HowToForge.
If they already have dozens of VMs, scores of containers, and they are fighting with monitoring and config management, then they might need k8s.
And a lot of folks do need this level of infrastructure and infrastructure management (automation, abstraction, standardization, etc).
> huh? What does that mean? Maybe that means the environment is broken, not the software you want to use/work on.
That is what the word "Enterprise IT" means. If you ever work in a company that makes more than a million USD per year, you will find an imperfect network in a nearly unknown state, with proxies and firewalls making your life hard, and automatic reconfiguration tools/scripts/antivirus-software resetting everything to "not working" the moment you take your eyes of the config files.
People and Software who really want to make money in Enterprise need to be able to handle that somehow. If you develop software on your macbook in an environment with the complexity of a Starbucks Wifi nobody can actually use your software in Enterprise.
Btw. did I mention that Windows+Outlook+Lync is the high standard of Enterprise laptops? Forget Enterprise users if you are not developing ON Windows.
k8s is a project, a lot of people find it useful. A lot of big corps have IT R&D groups (basically all Fortune 500 have), and they have their own test network. Or they test on their own rack, or on their own cloud, or on their own AWS account.
I think I don't really understand what your belief with regards to k8s is, but I'm interested, so could you give some details?
iterating on docker-compose might be easier/faster locally, then pushing to a dev k8s cluster for testing in ci/cd
curious if people are using k8s locally and why
Now I can't find a way to get the docker kubeconfig back, resetting the cluster, reinstalling kubernetes etc does nothing, and now that I have uninstalled and reinstalled docker, kubernetes doesn't even come up anymore. I'm also not allowed to share debug information with the Docker company. No real help from Docker developers without debug info. Because they can't tell me how docker generates a kubeconfig or where it writes its logs without seeing my diagnostics output...
Not the vanilla perfect world use case is what makes your software but how well your software manages edge cases.
As a developer one wants to spin up a system to work on, then work on it, then push results to some repo. And this loop simply isn't possible (yet?).
Also what the author didn't mention is that even the vanilla k8s stuff is already super complex. Let's assume you manage to setup a cluster somewhere and it continues to work for more than 2 days (rarely seen in real world work environments). Then you are faced with deploying your hello world app to work on. Just for a simple single-server nginx deployment with no files and no config, you already need to understand mutliple objects: deployments, replicasets, pods, containers, nodes, hosts, services, nodePorts, port-forwards, maybe even ingresses and controllers.
That means until you feel well, even in a perfect environment, you need several days or weeks. And the documentation is not really helping you there. Yes, it's better than most enterprise grade documentation out there, but still it assumes a lot of stuff upfront. For instance, why should a developer even know what an ingress is and that it might be something he needs?
Combine that huge learning overhead with nearly impossible network debugging, beta level stability, and the low possibility to "just use it", then you have a system that most developers will never touch.
Docker itself might survive though, and one of the good things of this CNCF world is that other alternatives to docker also get a chance to improve on the existing system.