Kubernetes - Do you use it?
-
And if so, why? I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take Exception -
And if so, why? I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionEverything you didn't write is hype.
-
And if so, why? I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI have no clue what all of these words mean. "Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management." :rolleyes:
I'd rather be phishing!
-
I have no clue what all of these words mean. "Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management." :rolleyes:
I'd rather be phishing!
Quote:
container-orchestration
They used to make drums out of old steel barrels. If they used a 60 ft. shipping container they would have enough for an entire orchestra. That's what these words must mean. I don't know about the rest of it.
- I would love to change the world, but they won’t give me the source code.
-
I have no clue what all of these words mean. "Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management." :rolleyes:
I'd rather be phishing!
Maximilien wrote:
"Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management."
The second half of that sentence sounds to me like what ARM templates are intended do on Azure. The first half is mostly gibberish to me.
-
I have no clue what all of these words mean. "Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management." :rolleyes:
I'd rather be phishing!
I use Kubernetes (and Docker obviously). Let's start with why I use Docker. With Docker, I build a series of images that can be applied to a container. What this simply means is that I have a number of steps described that get a system into a known and predictable state that can be applied from simple commands. In practice this means that I can say that I have a series of steps that describe how to build up (as an example), a Red Hat server running SQL Server. Now, that's great if you only want one of these running up, but what happens when you build a system that has tens or hundreds of these? That's where Kubernetes comes in. It makes managing these "on-demand" containers an absolute breeze.
-
And if so, why? I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI use Kubernetes (and Docker obviously). Let's start with why I use Docker. With Docker, I build a series of images that can be applied to a container. What this simply means is that I have a number of steps described that get a system into a known and predictable state that can be applied from simple commands. In practice this means that I can say that I have a series of steps that describe how to build up (as an example), a Red Hat server running SQL Server. Now, that's great if you only want one of these running up, but what happens when you build a system that has tens or hundreds of these? That's where Kubernetes comes in. It makes managing these "on-demand" containers an absolute breeze.
-
I have no clue what all of these words mean. "Kubernetes is an open-source container-orchestration system for automating application deployment, scaling, and management." :rolleyes:
I'd rather be phishing!
Maximilien wrote:
I have no clue what all of these words mean.
Exactly. It sounds like an open air symphony where the beer and wine are provided free by waiters and depending on how much you drink, you get a free ride back home.
Latest Articles:
Microservices: Myth, Madness, or Magic I Take Exception -
I use Kubernetes (and Docker obviously). Let's start with why I use Docker. With Docker, I build a series of images that can be applied to a container. What this simply means is that I have a number of steps described that get a system into a known and predictable state that can be applied from simple commands. In practice this means that I can say that I have a series of steps that describe how to build up (as an example), a Red Hat server running SQL Server. Now, that's great if you only want one of these running up, but what happens when you build a system that has tens or hundreds of these? That's where Kubernetes comes in. It makes managing these "on-demand" containers an absolute breeze.
Pete O'Hanlon wrote:
It makes managing these "on-demand" containers an absolute breeze.
Ah. OK, that starts to make sense. So it figures out the load requirements and spins up additional containers as necessary, and spins them down when the load goes down?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take Exception -
Pete O'Hanlon wrote:
It makes managing these "on-demand" containers an absolute breeze.
Ah. OK, that starts to make sense. So it figures out the load requirements and spins up additional containers as necessary, and spins them down when the load goes down?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionKubernetes is particularly useful at distributing work intelligently when modes are added/removed.
-
And if so, why? I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionI've used it - only for personal projects and not here at CodeProject so far, but I think I can write a bit about its usefulness. To start, there are two scenarios to consider: 1. You have to set up, maintain, and manage a Kubernetes cluster yourself. This can be a real pain, unless you have a Linux sysadmin handy, or enjoy being one yourself. 2. You're going to use a cloud Kubernetes service. Azure, AWS, and Google Cloud (along with lots of others) offer this, and it's the happy path for developers. I'll be discussing scenario 2 because it's the situation most developers find themselves in. I've found that Kubernetes is one of those things where you don't need it until you do, and when you do, it's really nice to have it. To jump on the Kubernetes bandwagon, you first have to jump on the container bandwagon. But it's a fairly easy bandwagon to jump on, conceptually. It's a nice way of ensuring that your app is running in very close to the same environment in production as it was while in development. This cuts down on those good old bugs where everything works on the developer's machine, then goes to hell in production. It also makes deployment nice and easy. You push your changes to your app's Git repository, then your CI system builds your application and if all the tests pass, bundles it up into a container and pushes that container to a container registry like Docker Hub or Azure Container Registry. Or you can do things the old fashioned way and build the app on your own machine, run the tests (you do have tests, right?), and then manually build the container and push it to a registry. Now, it's time to deploy. You sign in to your production server and run a command that basically says "hey Docker, pull the latest version of my app from the registry" and poof! Magic! The latest version of your app is on the production server. At this point, you'll usually need to ask Docker to restart the container too, to ensure that the newest version is running. That took a couple of steps, but it's still pretty nice. No XCOPYing files to servers. No copy-and-pasting via remote desktop. No weird errors caused by forgetting to install a dependency your app needs. Since your app's container is self-contained and has all of the dependencies included, it just works reliably every time. This is all well and good, and it's often a step up from the ad-hoc prayer and duct tape-based deployment processes that a shocking number of dev teams are using. But it all falls apart when your applica
-
And if so, why? I've not jumped onto the container bandwagon yet and probably won't, but I keep seeing all this support hype regarding Kubernetes. Hype, or some usefulness?
Latest Articles:
Microservices: Myth, Madness, or Magic I Take ExceptionNot yet, but we are planning to use it in the future. More information here: resources-to-learn-about-docker-deployment~kubernetes-documentation[^] :-\
-
I've used it - only for personal projects and not here at CodeProject so far, but I think I can write a bit about its usefulness. To start, there are two scenarios to consider: 1. You have to set up, maintain, and manage a Kubernetes cluster yourself. This can be a real pain, unless you have a Linux sysadmin handy, or enjoy being one yourself. 2. You're going to use a cloud Kubernetes service. Azure, AWS, and Google Cloud (along with lots of others) offer this, and it's the happy path for developers. I'll be discussing scenario 2 because it's the situation most developers find themselves in. I've found that Kubernetes is one of those things where you don't need it until you do, and when you do, it's really nice to have it. To jump on the Kubernetes bandwagon, you first have to jump on the container bandwagon. But it's a fairly easy bandwagon to jump on, conceptually. It's a nice way of ensuring that your app is running in very close to the same environment in production as it was while in development. This cuts down on those good old bugs where everything works on the developer's machine, then goes to hell in production. It also makes deployment nice and easy. You push your changes to your app's Git repository, then your CI system builds your application and if all the tests pass, bundles it up into a container and pushes that container to a container registry like Docker Hub or Azure Container Registry. Or you can do things the old fashioned way and build the app on your own machine, run the tests (you do have tests, right?), and then manually build the container and push it to a registry. Now, it's time to deploy. You sign in to your production server and run a command that basically says "hey Docker, pull the latest version of my app from the registry" and poof! Magic! The latest version of your app is on the production server. At this point, you'll usually need to ask Docker to restart the container too, to ensure that the newest version is running. That took a couple of steps, but it's still pretty nice. No XCOPYing files to servers. No copy-and-pasting via remote desktop. No weird errors caused by forgetting to install a dependency your app needs. Since your app's container is self-contained and has all of the dependencies included, it just works reliably every time. This is all well and good, and it's often a step up from the ad-hoc prayer and duct tape-based deployment processes that a shocking number of dev teams are using. But it all falls apart when your applica
-
I've used it - only for personal projects and not here at CodeProject so far, but I think I can write a bit about its usefulness. To start, there are two scenarios to consider: 1. You have to set up, maintain, and manage a Kubernetes cluster yourself. This can be a real pain, unless you have a Linux sysadmin handy, or enjoy being one yourself. 2. You're going to use a cloud Kubernetes service. Azure, AWS, and Google Cloud (along with lots of others) offer this, and it's the happy path for developers. I'll be discussing scenario 2 because it's the situation most developers find themselves in. I've found that Kubernetes is one of those things where you don't need it until you do, and when you do, it's really nice to have it. To jump on the Kubernetes bandwagon, you first have to jump on the container bandwagon. But it's a fairly easy bandwagon to jump on, conceptually. It's a nice way of ensuring that your app is running in very close to the same environment in production as it was while in development. This cuts down on those good old bugs where everything works on the developer's machine, then goes to hell in production. It also makes deployment nice and easy. You push your changes to your app's Git repository, then your CI system builds your application and if all the tests pass, bundles it up into a container and pushes that container to a container registry like Docker Hub or Azure Container Registry. Or you can do things the old fashioned way and build the app on your own machine, run the tests (you do have tests, right?), and then manually build the container and push it to a registry. Now, it's time to deploy. You sign in to your production server and run a command that basically says "hey Docker, pull the latest version of my app from the registry" and poof! Magic! The latest version of your app is on the production server. At this point, you'll usually need to ask Docker to restart the container too, to ensure that the newest version is running. That took a couple of steps, but it's still pretty nice. No XCOPYing files to servers. No copy-and-pasting via remote desktop. No weird errors caused by forgetting to install a dependency your app needs. Since your app's container is self-contained and has all of the dependencies included, it just works reliably every time. This is all well and good, and it's often a step up from the ad-hoc prayer and duct tape-based deployment processes that a shocking number of dev teams are using. But it all falls apart when your applica
> and if all the tests pass :laugh:
Ryan Peden wrote:
and this message is starting to approach article length.
I was just thinking that as I rounded the final couple bends in your post. Awesome writeup!!! Thank you!
Latest Articles:
Microservices: Myth, Madness, or Magic I Take Exception -
I've used it - only for personal projects and not here at CodeProject so far, but I think I can write a bit about its usefulness. To start, there are two scenarios to consider: 1. You have to set up, maintain, and manage a Kubernetes cluster yourself. This can be a real pain, unless you have a Linux sysadmin handy, or enjoy being one yourself. 2. You're going to use a cloud Kubernetes service. Azure, AWS, and Google Cloud (along with lots of others) offer this, and it's the happy path for developers. I'll be discussing scenario 2 because it's the situation most developers find themselves in. I've found that Kubernetes is one of those things where you don't need it until you do, and when you do, it's really nice to have it. To jump on the Kubernetes bandwagon, you first have to jump on the container bandwagon. But it's a fairly easy bandwagon to jump on, conceptually. It's a nice way of ensuring that your app is running in very close to the same environment in production as it was while in development. This cuts down on those good old bugs where everything works on the developer's machine, then goes to hell in production. It also makes deployment nice and easy. You push your changes to your app's Git repository, then your CI system builds your application and if all the tests pass, bundles it up into a container and pushes that container to a container registry like Docker Hub or Azure Container Registry. Or you can do things the old fashioned way and build the app on your own machine, run the tests (you do have tests, right?), and then manually build the container and push it to a registry. Now, it's time to deploy. You sign in to your production server and run a command that basically says "hey Docker, pull the latest version of my app from the registry" and poof! Magic! The latest version of your app is on the production server. At this point, you'll usually need to ask Docker to restart the container too, to ensure that the newest version is running. That took a couple of steps, but it's still pretty nice. No XCOPYing files to servers. No copy-and-pasting via remote desktop. No weird errors caused by forgetting to install a dependency your app needs. Since your app's container is self-contained and has all of the dependencies included, it just works reliably every time. This is all well and good, and it's often a step up from the ad-hoc prayer and duct tape-based deployment processes that a shocking number of dev teams are using. But it all falls apart when your applica
Quote:
Hm, I think I'd better end this here. I came in intending to do a brief overview, and this message is starting to approach article length. :) I've mostly just scratched the surface. I've skipped lots of details
I've never had enough interest in Kubernetes to read much about it, but I did leave a browser tab opened until I had time to come back to it and read your write-up just now. This is absolutely an article I would read, if you'd care to add those details you've skipped. You have a writing style that has kept me interested throughout, and I'd be interested in knowing what else you think might be important in an overview.