FWIWI a few days back I upgraded my microk8s-based k8s to 1.18 beta channel and it solved at least ImagePullBackOff problem that I had with pulling from my private GitLab registry.
Worked like charm.
Kubernetes 1.18
101–110 of 132 posts
Re: Kubernetes 1.18
#102Shamelesss plug: Keights, my Kubernetes installer[1] for AWS supports 1.18 (the latest version available on EKS is 1.15). Keights also supports running etcd separate from the control plane, lets you choose instance sizes for the control plane, and can run in GovCloud. 1. https://github.com/cloudboss/keights
How does it compare to kops or, dare I say it, kubespray?
Re: Kubernetes 1.18
#103Earlier quoted context omitted.
I'm sorry but this reads like some mix of a sales pitch and religious preaching. K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them. It also assumes out of the gate that everything needs to be able to do HA, scale for 1,000,000 instances/s etc... Over and over and over people show examples (I'm guilty too) of running internet scale applications on a single load…
> K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them. Kubernetes does not black box anything. At most it abstracts the computer cluster comprised of heterogeneous COTS computers, as well as the heterogeneous networks they communicate over and the OS they run on. I'm starting to believe that the bulk of the criticism directed at Kubernetes is made up by arrogant…
It's the exact opposite. I don't think that's stuff should be abstracted away.
Re: Kubernetes 1.18
#104Although I understand the fear that many have of being left behind the technology curve by not having the time - or the chance - to run Kubernetes in their day to day work, we really must appreciate that Kubernetes really is the future of infrastructure. For those that are looking at Kubernetes with suspicion, it is a natural instinct to think of K8s as a threat to all the knowledge we have built in the past few year…
I'm sorry but this reads like some mix of a sales pitch and religious preaching. K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them. It also assumes out of the gate that everything needs to be able to do HA, scale for 1,000,000 instances/s etc... Over and over and over people show examples (I'm guilty too) of running internet scale applications on a single load…
> K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them. It also assumes out of the gate that everything needs to be able to do HA, scale for 1,000,000 instances/s etc...
What I've seen, anecdotally, is that many ops-background people don't "get" why kubernetes is such a big deal. They assert rightfully that they can already do everything, they already know how to do everything, and they can do it without the overhead (both cognitively and in terms of resource utilization) of k8s.
But, if you are writing and deploying code - especially if you're not in a terribly agile organization - k8s eases so many real pain points that "old" models have which ops teams may be only vaguely aware of. If you need a certain dependency, if you need to deploy any new software, an entire new language or approach, if you need a new service, you now have the ability to directly do it immediately.
I can't tell you what a big deal it is going to be for a developer at a random bigco to be able to run their code without waiting for ops to craft a VM with all the right bits for them.
k8s solves real problems. If you have a monolith and need to solve how to scale it, that's not where k8s shines. But with lots of small workloads, or dynamic workloads, or existing dev vs ops organizational hurdles, it can really be a game changer.
Re: Kubernetes 1.18
#105Earlier quoted context omitted.
> K8S doesn't eliminate the workflow for "deployments, upgrades, monitoring, etc.." it just black boxes them. Kubernetes does not black box anything. At most it abstracts the computer cluster comprised of heterogeneous COTS computers, as well as the heterogeneous networks they communicate over and the OS they run on. I'm starting to believe that the bulk of the criticism directed at Kubernetes is made up by arrogant…
It's the exact opposite. I don't think that's stuff should be abstracted away.
> It's the exact opposite. I don't think that's stuff should be abstracted away.
Why not? The Kubernetes/serverless/DevOps people have a compelling argument--organizations can move faster when dev teams don't have to coordinate with an ops/sysadmin function to get anything done. If the ops/sysadmin/whatever team instead manages a Kubernetes cluster and devs can simply be self-service users of that cluster, then they can move faster. That's the sales pitch, and it seems reasonable (and I've seen it work in practice when our team transitioned from a traditional sysadmin/ops workflow to Fargate/DevOps). If you want to persuade me otherwise, tell me about the advantages of having an ops team assemble and gatekeep a bespoke platform and why those advantages are better than the k8s/serverless/DevOps position.
Re: Kubernetes 1.18
#106I'm pleased to see the changes in the HPA, having pod scale-up/down periods be tied to a systemwide setting was a bit painful.
This one?
https://github.com/kubernetes/kubernetes/blob/master/CHANGEL...
> autoscaling/v2beta2 HorizontalPodAutoscaler added a spec.behavior field that allows scale behavior to be configured. Behaviors are specified separately for scaling up and down. In each direction a stabilization window can be specified as well as a list of policies and how to select amongst them. Policies can limit the absolute number of pods added or removed, or the percentage of pods added or removed. (#74525, @gliush) [SIG API Machinery, Apps, Autoscaling and CLI]
Re: Kubernetes 1.18
#107Earlier quoted context omitted.
> It makes no sense to quota your cpu with the exception of very specific cases (like metered usage). This is not true at all. Autoscaling depends on CPU quotas. More importantly, if you want to keep your application running well without getting chatty neighbors or getting your containers redeployed around for no apparent reason, you need to cover all resources with quotas.
Agree re noisy neighbours, but autoscaling depends on _requests_ rather than _limits_, so you could define requests for HPA scaling but leave out the limits and have both autoscaling and no throttling.
The problem with having no throttling is that the system will just keep on running happily, until you get to the point where resources become more limited. You will not get any early feedback that your system is constantly underprovisioned. Try doing this on a multi-tenant cluster, where new pods spawned by other teams/people come and go constantly. You won't be able to get any reliable performance characteristics in environments like that.
For such clusters, it's necessary to set up stuff like the LimitRanger (https://kubernetes.io/docs/concepts/policy/limit-range/) to put a hard constant bound between requests and limits.
Re: Kubernetes 1.18
#108Earlier quoted context omitted.
You can migrate docker deployments to K8s just by adding the parts you were missing, so when in doubt, it always makes sense to start with docker, docker-compose, and only consider K8s as an alternative to docker swarm.
I actually spent the past 3 days attempting to migrate my DIY “docker instances managed by systemd” setup to k8s, and found getting started to be a huge pain in the ass, eventually giving up when none of the CNIs seemed to work (my 3 physical hosts could ping each other and ping all the different service addresses, but containers couldn’t ping each other’s service addresses). That said, if anyone REALLY wants to go t…
This should be really easy using k3s.
Re: Kubernetes 1.18
#109Earlier quoted context omitted.
It's the exact opposite. I don't think that's stuff should be abstracted away.
> It's the exact opposite. I don't think that's stuff should be abstracted away. Why not? The Kubernetes/serverless/DevOps people have a compelling argument--organizations can move faster when dev teams don't have to coordinate with an ops/sysadmin function to get anything done. If the ops/sysadmin/whatever team instead manages a Kubernetes cluster and devs can simply be self-service users of that cluster, then they…
One of the things I see ignored in these discussions is the strategic timeline. Yes, dev teams can yeet out software like crazy without an ops team. But eventually you build up this giant mass of software the dev team is responsible for. Ops was never involved until one day the mgmt chain for the dev team realizes he can free up a bunch of capacity by dumping his responsibilities onto ops.
IMO, some of these practices come from businesses with huge rivers of money who can hire and retain world class talent. I’d like to see some case studies of how it works when your tiny DevOps team is spending 80% of their time managing a huge portfolio of small apps. How then do you deliver “new, shiny” business value and keep devs and business stakeholders engaged and onboard?
Re: Kubernetes 1.18
#110I've taken a couple k8s courses, I understand all the small parts that make up k8s, but yet it seems that there are still no easy solutions to install on bare metal. The default recommendation is to always just roll with a managed solution. This is slightly irritating considering there are plently of companies out there who own their own infrastructure.
There are plenty of great developer distributions out there (k3s, kind, minikube, microk8s), but those are single node only, and aren't meant for production use.
I'm still searching for a solid guide on how to get k8s installed on your own hardware. Any suggestions would be very appreciated!