4 ms·

To be fair. Just last night i was googling kubernetes and k3s tutorials. All of them on page 1 of SERPS are super simple and brilliant and ONLY show you how to

To be fair. Just last night i was googling kubernetes and k3s tutorials. All of them on page 1 of SERPS are super simple and brilliant and ONLY show you how to add nodes to clusters. Ok now what ?? Ive drank the k-Koolaid signup for the newsletters but how do i get value from this 'thing' ??? When i code a webapp how do setup/config the db ? How do I do a regular LAMP app ? Lol i never thought i say this but i need a kubernetes tutorial on 'best practices' for common patterns. No for google scale but how do i kubernetify my run of the mil lamp app with 100kpage views a month ?? There seems to be a gap between the beginner and advance (kubernetes all things) levels ? Maybe that is the answer ?? The fact that the middle-situations(lamp apps with low-med traffic) tutorials dont exists means i dont need it ??

ancieque 4y ago
I would recommend Bret Fisher tutorials https://www.bretfisher.com/ https://www.bretfisher.com/
vbezhenar 4y ago
All you need exists on kubernetes.io. Start with https://kubernetes.io/docs/tutorials/hello-minikube/ https://kubernetes.io/docs/tutorials/hello-minikube/ and proceed. Read reference documentation on the same site whenever you need to dig somewhere. It's awesome. You don't need any other websites. I was able to build a kubernetes cluster and right now deploying multi-service application and I have had enough technical information on this website alone. As to answer your questions: You can start with DB as an ordinary container in a statefulset deployment. It's similar to docker. You configure it with environment variables. Advanced approach is operators, but you don't need those for simple start. Connection to DB is the same like docker. You use Kubernetes secrets instead of docker secrets and that's about it. My message assumes that you're proficient with docker. If you're not, I suggest to first learning docker. May be you don't need Kubernetes for your scale at all. And if you do, most docker concepts make sense in Kubernetes anyway.
- rawoke083600 4y ago
  Cool thanks will have a look. Id be more interesting on where kubernetes (redundancy) fits into traditional redundancy ? Examples: 1. Do i still need gluster/ceph or do i use the longhorn thing ? 2. Db replication? Do i use the usual solutions of master-slaves and clusters or does multiple k-nodes take that over ? 3. Webserver LB with failover ? Do i use LB from hosting vendor, haproxy or does kubernetes have its own thing ?? From what I can tell as a kubernetes-noob the value is: 1) Reproducibility 2) Reliability via redundancy 3) AutoScaling. All of the abkve has to some degree a previous/current solution , so which do i give up/replace with kubernetes-tool ? Sorry yes Im a k-noob
  - timhaak 4y ago
    1 It depends. For larger scale gluster or ceph. But quiet a bit more work. Longhorn you can get up and working quickly. Though if you are on a cloud provider just use their storage system. 2 K8 doesn't magically solve replication unfortunately. Though there are helm charts that will automatically set up a replicated setup for you. I still need to solve backups. Once again if you are on a cloud provide. Just use their Db offering. 3 K8 doesn't have a default out of the box. The repo shows you how to setup traefik to handle this. On cloud providers they have normally integrated it with their lb already. For me the large advantages are reproducibility and no vendor lock in. Also give redundancy and quiet a bit of automation once set up. Auto scaling is always tricky. Lastly if you have the skills it can be far cheaper to run your own in metal. If you don't the the time most likely would be better spent actually coding. Depending where you are in the world and the relevant pay scales.
  - vbezhenar 4y ago
    I'll try to answer, but keep in mind that I'm newbie myself. > 1. Do i still need gluster/ceph or do i use the longhorn thing ? Kubernetes does not care about storage implementation. It contains some abstract ways to request a storage (PersistentVolumeClaim). And then some particular Kubernetes installation will fulfil this request with PersistentVolume. So basically it comes down to your Kubernetes provider. It should have some instructions about volume classes that you can use. If you're installing your Kubernetes on bare metal, you need to think about this aspect yourself, of course. Both ceph and glusterfs are popular options and there're good Kubernetes drivers for it. You can also just use local storage, like docker does, but of course it'll not survive server outage, so it limits your availability. I'm installing my cluster on OpenStack. There's Cinder CSI plugin for Kubernetes, so it provides me storage when I ask for it. My provider uses SAN for one type of volume and Ceph for other type of volume. I think that simplest solution is some kind of NFS server. Kubernetes can consume it as well. > 2. Db replication? Do i use the usual solutions of master-slaves and clusters or does multiple k-nodes take that over ? Basically Kubernetes does not care about your particular configuration. It runs containers and provides those containers with storage, DNS, network, etc. So it's up to you. You can configure database replication with your own tools and scripts if you like. I have had good experience with CloudNativePG. It's so-called Kubernetes Operator. Basically it's a thing that configures database clusters for (postgres) given abstract definition. It can configure master-slaves cluster and it allows for easy backup configuration to S3 storage. There're other operators as well, for almost any popular database. So probably it's better to use those, unless you're very good at database operations. And in the true clouds it might be a good idea to use managed database and not to think about it at all. > 3. Webserver LB with failover ? Do i use LB from hosting vendor, haproxy or does kubernetes have its own thing ?? You need some kind of external load balancer to deliver packets in a high-available way. My hoster provides that as part of its OpenStack package. I guess that every cloud hoster provides it. If you're using bare metal, you need some kind of haproxy and keepalived setup (or some kind of hardware load balancer, I have no idea). This external load balancer have to deliver TCP packets to your worker nodes. Like 1.2.3.4:80 -> 10.1.1.1:30080, 10.11.1.2:30080, 10.11.1.3:30080. And once Kubernetes receives those packets in a high-available way, it routes them as needed. Usually you have ingress controller which provides HTTPS, and then uses HTTP host and path to route request to some pod which serves it in the end. Once request reached Kubernetes, it'll make sure to route it the right way. If your pods deployed in 2+ replicas, it'll be high-available. If your pod deployed in 1 replica and server is died, Kubernetes eventually will reschedule that pod to another server, but there'll be service interruption for a few minutes. So everything high-available should be deployed in 2+ replicas. > From what I can tell as a kubernetes-noob the value is: 1) Reproducibility 2) Reliability via redundancy 3) AutoScaling. Here's my take on Kubernetes value. First is it introduces a language connecting developers and operations. It is important. You don't need developers to hand-waive which ports they need to expose, which services they need to consume and which HTTP routes they need to receive for that particular server. They've got language to express how their service should be used. Second is it provides high-available cluster. And in my testing it's quite stable. My only issue is that it takes too much time to reschedule pods from dead server. I expected it to take few seconds, but it took few minutes. I don't yet know why is that. Third and one I didn't really expect when started to learn it: it provides high-quality solutions for some hard problems. I mentioned database clustering and database backup. I can deploy database with single 50-lines YAML mostly copy&pasted from the example. It'll start master and slave pods and it'll provide continuous backup to S3 using barman. I don't have skills to configure that kind of setup and I expect that I'd need a week at least to come to that setup. Another problem is letsencrypt. Well, it's not that hard, but I've spent many hours debugging some convoluted nginx/caddy/whatever net of docker containers trying to figure out what letsencrypt does not work there. With Kubernetes cert-manager it's just works. All configuration is centralized, all services write ingress and they've got their TLS certificate automagically, whether it's HTTP-01 solver, DNS-01 solver, it's just abstracted away. It has some steep learning curve, that's for sure. Even more so, if you want to deploy it yourself rather than using managed one. I suggest to use managed one if you can. I have some circumstances which prevent me to using managed Kubernetes, but I plan to migrate to managed as soon as I can. It's not that hard, but it takes time and managed Kubernetes is cheap enough. If you can't use managed Kubernetes, try to find a provider with OpenStack API. It'll help with load balancers and storage provisioning. Autoscaling - that part I didn't solve yet. It's not easy if you're not using managed Kubernetes. But if you're using managed Kubernetes, it should be as easy as ticking a checkbox somewhere. > All of the above has to some degree a previous/current solution , so which do i give up/replace with kubernetes-tool ? Well, right now we're using three dedicated servers with docker-composes scattered all over, made with ad-hoc scripts and whatnot, partially working backups, no observability. Chaos. Kubernetes for us looks like a very promising way to throw away that chaos and rebuild operations correctly.
ericbarrett 4y ago
> Maybe that is the answer ?? The fact that the middle-situations(lamp apps with low-med traffic) tutorials dont exists means i dont need it ?? SRE for 15 years with FAANG (MAGMA?) scale experience; I would argue this, yes. That's a little over 2 requests per minute. If you're cloud hosting then you could get away with single tiny hosts for your front end and DB, like t3.small on AWS, and Cloudwatch alarms for monitoring. If you need extreme HA or burstability even with this low rate, a managed load balancer (e.g. AWS ALB) with a few target webservers will do the trick and let you swap them out as needed without taking down the site. A DB read replica will give you redundancy there as well. This is all 20-year-old tried and true tech. You'll set it up once and it will run for years without trouble. Once you introduce Kubernetes you've got a whole 'nother beast to feed, especially if it's self-managed, and you'll pay dearly if it's not (like EKS). For your scale, it would be kind of like buying a full sized semi truck to haul stuff for a corner store. You'd be better served with a small pickup or minivan. Of course you don't need an "at scale" excuse to learn new tech. In which case I agree there's a dearth of practical tutorials that aren't just "here's a Helm chart." Part of this is because managing a stateful service like MySQL on K8s is not straightforward; there's a lot of ways to do it, most of them are wrong, new ways get introduced every few years, and even people who claim they've solved the issue are probably sitting on a time bomb of their own making and have just gotten lucky.
- elbigbad 4y ago
  Our platform team got into k8s for some reason at my company. Because it’s enterprise there’s never really the “millions of requests per second” sort of problems because every deployment is single tenant. We have experienced k8s engineers who I guess we’re just using the tools we know, but wow it’s been such a hassle and has caused so much toil. Right now we’re having trouble scaling back ends for parallel jobs with k8s, which is a problem we easily solved with regular tooling in the past pre-k8s.
  - cjalmeida 4y ago
    On enterprises, k8s solves a different kind of scaling problem. You tend to have hundreds of apps that are business critical and need to be managed. K8s provides a consistent way to package, deploy with HA and monitor those apps. Ideally it replaced tons of ad-hoc scripts and confluence pages that are very poorly maintained.
MuffinFlavored 4y ago
> SERPS Search Engine Result Pages
cloudfive 4y ago
(disclaimer: I work for a Bunnyshell) Honestly the most benefit would be gained from making Kubernetes invisible and speeding up your development process. Tools exist now to deploy short lived preview environments into your cluster for every PR. This is where the Kubernetes values sits. The whole “shift left” idea. Test before merge / identical short lived environments, etc.

ancieque 4y ago

I would recommend Bret Fisher tutorials https://www.bretfisher.com/ https://www.bretfisher.com/

vbezhenar 4y ago

All you need exists on kubernetes.io. Start with https://kubernetes.io/docs/tutorials/hello-minikube/ https://kubernetes.io/docs/tutorials/hello-minikube/ and proceed. Read reference documentation on the same site whenever you need to dig somewhere. It's awesome. You don't need any other websites. I was able to build a kubernetes cluster and right now deploying multi-service application and I have had enough technical information on this website alone. As to answer your questions: You can start with DB as an ordinary container in a statefulset deployment. It's similar to docker. You configure it with environment variables. Advanced approach is operators, but you don't need those for simple start. Connection to DB is the same like docker. You use Kubernetes secrets instead of docker secrets and that's about it. My message assumes that you're proficient with docker. If you're not, I suggest to first learning docker. May be you don't need Kubernetes for your scale at all. And if you do, most docker concepts make sense in Kubernetes anyway.

rawoke083600 4y ago
Cool thanks will have a look. Id be more interesting on where kubernetes (redundancy) fits into traditional redundancy ? Examples: 1. Do i still need gluster/ceph or do i use the longhorn thing ? 2. Db replication? Do i use the usual solutions of master-slaves and clusters or does multiple k-nodes take that over ? 3. Webserver LB with failover ? Do i use LB from hosting vendor, haproxy or does kubernetes have its own thing ?? From what I can tell as a kubernetes-noob the value is: 1) Reproducibility 2) Reliability via redundancy 3) AutoScaling. All of the abkve has to some degree a previous/current solution , so which do i give up/replace with kubernetes-tool ? Sorry yes Im a k-noob
- timhaak 4y ago
  1 It depends. For larger scale gluster or ceph. But quiet a bit more work. Longhorn you can get up and working quickly. Though if you are on a cloud provider just use their storage system. 2 K8 doesn't magically solve replication unfortunately. Though there are helm charts that will automatically set up a replicated setup for you. I still need to solve backups. Once again if you are on a cloud provide. Just use their Db offering. 3 K8 doesn't have a default out of the box. The repo shows you how to setup traefik to handle this. On cloud providers they have normally integrated it with their lb already. For me the large advantages are reproducibility and no vendor lock in. Also give redundancy and quiet a bit of automation once set up. Auto scaling is always tricky. Lastly if you have the skills it can be far cheaper to run your own in metal. If you don't the the time most likely would be better spent actually coding. Depending where you are in the world and the relevant pay scales.
- vbezhenar 4y ago
  I'll try to answer, but keep in mind that I'm newbie myself. > 1. Do i still need gluster/ceph or do i use the longhorn thing ? Kubernetes does not care about storage implementation. It contains some abstract ways to request a storage (PersistentVolumeClaim). And then some particular Kubernetes installation will fulfil this request with PersistentVolume. So basically it comes down to your Kubernetes provider. It should have some instructions about volume classes that you can use. If you're installing your Kubernetes on bare metal, you need to think about this aspect yourself, of course. Both ceph and glusterfs are popular options and there're good Kubernetes drivers for it. You can also just use local storage, like docker does, but of course it'll not survive server outage, so it limits your availability. I'm installing my cluster on OpenStack. There's Cinder CSI plugin for Kubernetes, so it provides me storage when I ask for it. My provider uses SAN for one type of volume and Ceph for other type of volume. I think that simplest solution is some kind of NFS server. Kubernetes can consume it as well. > 2. Db replication? Do i use the usual solutions of master-slaves and clusters or does multiple k-nodes take that over ? Basically Kubernetes does not care about your particular configuration. It runs containers and provides those containers with storage, DNS, network, etc. So it's up to you. You can configure database replication with your own tools and scripts if you like. I have had good experience with CloudNativePG. It's so-called Kubernetes Operator. Basically it's a thing that configures database clusters for (postgres) given abstract definition. It can configure master-slaves cluster and it allows for easy backup configuration to S3 storage. There're other operators as well, for almost any popular database. So probably it's better to use those, unless you're very good at database operations. And in the true clouds it might be a good idea to use managed database and not to think about it at all. > 3. Webserver LB with failover ? Do i use LB from hosting vendor, haproxy or does kubernetes have its own thing ?? You need some kind of external load balancer to deliver packets in a high-available way. My hoster provides that as part of its OpenStack package. I guess that every cloud hoster provides it. If you're using bare metal, you need some kind of haproxy and keepalived setup (or some kind of hardware load balancer, I have no idea). This external load balancer have to deliver TCP packets to your worker nodes. Like 1.2.3.4:80 -> 10.1.1.1:30080, 10.11.1.2:30080, 10.11.1.3:30080. And once Kubernetes receives those packets in a high-available way, it routes them as needed. Usually you have ingress controller which provides HTTPS, and then uses HTTP host and path to route request to some pod which serves it in the end. Once request reached Kubernetes, it'll make sure to route it the right way. If your pods deployed in 2+ replicas, it'll be high-available. If your pod deployed in 1 replica and server is died, Kubernetes eventually will reschedule that pod to another server, but there'll be service interruption for a few minutes. So everything high-available should be deployed in 2+ replicas. > From what I can tell as a kubernetes-noob the value is: 1) Reproducibility 2) Reliability via redundancy 3) AutoScaling. Here's my take on Kubernetes value. First is it introduces a language connecting developers and operations. It is important. You don't need developers to hand-waive which ports they need to expose, which services they need to consume and which HTTP routes they need to receive for that particular server. They've got language to express how their service should be used. Second is it provides high-available cluster. And in my testing it's quite stable. My only issue is that it takes too much time to reschedule pods from dead server. I expected it to take few seconds, but it took few minutes. I don't yet know why is that. Third and one I didn't really expect when started to learn it: it provides high-quality solutions for some hard problems. I mentioned database clustering and database backup. I can deploy database with single 50-lines YAML mostly copy&pasted from the example. It'll start master and slave pods and it'll provide continuous backup to S3 using barman. I don't have skills to configure that kind of setup and I expect that I'd need a week at least to come to that setup. Another problem is letsencrypt. Well, it's not that hard, but I've spent many hours debugging some convoluted nginx/caddy/whatever net of docker containers trying to figure out what letsencrypt does not work there. With Kubernetes cert-manager it's just works. All configuration is centralized, all services write ingress and they've got their TLS certificate automagically, whether it's HTTP-01 solver, DNS-01 solver, it's just abstracted away. It has some steep learning curve, that's for sure. Even more so, if you want to deploy it yourself rather than using managed one. I suggest to use managed one if you can. I have some circumstances which prevent me to using managed Kubernetes, but I plan to migrate to managed as soon as I can. It's not that hard, but it takes time and managed Kubernetes is cheap enough. If you can't use managed Kubernetes, try to find a provider with OpenStack API. It'll help with load balancers and storage provisioning. Autoscaling - that part I didn't solve yet. It's not easy if you're not using managed Kubernetes. But if you're using managed Kubernetes, it should be as easy as ticking a checkbox somewhere. > All of the above has to some degree a previous/current solution , so which do i give up/replace with kubernetes-tool ? Well, right now we're using three dedicated servers with docker-composes scattered all over, made with ad-hoc scripts and whatnot, partially working backups, no observability. Chaos. Kubernetes for us looks like a very promising way to throw away that chaos and rebuild operations correctly.

ericbarrett 4y ago

> Maybe that is the answer ?? The fact that the middle-situations(lamp apps with low-med traffic) tutorials dont exists means i dont need it ?? SRE for 15 years with FAANG (MAGMA?) scale experience; I would argue this, yes. That's a little over 2 requests per minute. If you're cloud hosting then you could get away with single tiny hosts for your front end and DB, like t3.small on AWS, and Cloudwatch alarms for monitoring. If you need extreme HA or burstability even with this low rate, a managed load balancer (e.g. AWS ALB) with a few target webservers will do the trick and let you swap them out as needed without taking down the site. A DB read replica will give you redundancy there as well. This is all 20-year-old tried and true tech. You'll set it up once and it will run for years without trouble. Once you introduce Kubernetes you've got a whole 'nother beast to feed, especially if it's self-managed, and you'll pay dearly if it's not (like EKS). For your scale, it would be kind of like buying a full sized semi truck to haul stuff for a corner store. You'd be better served with a small pickup or minivan. Of course you don't need an "at scale" excuse to learn new tech. In which case I agree there's a dearth of practical tutorials that aren't just "here's a Helm chart." Part of this is because managing a stateful service like MySQL on K8s is not straightforward; there's a lot of ways to do it, most of them are wrong, new ways get introduced every few years, and even people who claim they've solved the issue are probably sitting on a time bomb of their own making and have just gotten lucky.

elbigbad 4y ago
Our platform team got into k8s for some reason at my company. Because it’s enterprise there’s never really the “millions of requests per second” sort of problems because every deployment is single tenant. We have experienced k8s engineers who I guess we’re just using the tools we know, but wow it’s been such a hassle and has caused so much toil. Right now we’re having trouble scaling back ends for parallel jobs with k8s, which is a problem we easily solved with regular tooling in the past pre-k8s.
- cjalmeida 4y ago
  On enterprises, k8s solves a different kind of scaling problem. You tend to have hundreds of apps that are business critical and need to be managed. K8s provides a consistent way to package, deploy with HA and monitor those apps. Ideally it replaced tons of ad-hoc scripts and confluence pages that are very poorly maintained.

MuffinFlavored 4y ago

> SERPS Search Engine Result Pages

cloudfive 4y ago

(disclaimer: I work for a Bunnyshell) Honestly the most benefit would be gained from making Kubernetes invisible and speeding up your development process. Tools exist now to deploy short lived preview environments into your cluster for every PR. This is where the Kubernetes values sits. The whole “shift left” idea. Test before merge / identical short lived environments, etc.