I apologize if this is an ignorant question but I am building out a Kubernetes cluster and I really like the idea of abstracting my computing infrastructure from a single cloud provider and steering away from a VM platform but what about statefulness? I want to be able to setup a mysql server for example and keep that data for life, I want Kubernetes to load balance a mysql container with a data drive, we speak about containers and we think life and death within seconds but what about when we want to keep data around and build a kick ass data center without VM's is there a concept of of being stateful in this paradigm?
Kubernetes provides StatefulSets for Deploying stateful containers like databases. Follow the below link to understand how to deploy mysql database In highly available mode
https://kubernetes.io/docs/tasks/run-application/run-replicated-stateful-application/
Not ignorant at all, in fact, stateful apps (often DBs) require special consideration in Kubernetes.
StatefulSets are one of the primary Kubernetes objects that exist to help support the use of stateful apps.
This is a decent guide to solving some of the challenges. It's written by Google for Kubernetes Engine but the concepts apply to Kubernetes broadly. There is also a GKE-specific overview.
Related
I just started looking at Temporal and it looks like a great way to orchestrate microservices. I have knative & cloudrun based microservices in my project and I would like to adapted Temporal to orchestrate the workflow between my services.
From a quick look through docs I couldn't figure out if Temporal can manage serverless microservices (knative/cloudrun). Have you used Temporal and do you have serverless workloads in your project? If so can you share your experience?
Thanks
It looks like all temporal code runs inside a (persistent) temporal server. That probably makes it a poor fit for an environment like Cloud Run or Knative (or AWS Lambda containers).
Looking further through the doc, it also appears that multiple temporal servers end up individually addressing each other through their own clustering protocol.
From the video at the start, it does seem like you could use an Activity to encapsulate a call to a service running on Knative or Cloud Run.
I have a monolithic application based on .NET , the application itself is a web based app.
I am looking at multiple articles and trying to figure out if the Azure CI or similar would be an correct service to use.
The application will run 24/7 and i guess this is where confusion comes in, wouldn't it be normal to have always on application running on CI?
What i am trying to achieve is a container per customer where each customer gets one or more instances that he owns. The other question would be costs and scalability, i would expect to have thousands of containers so perhaps i should be looking at Kubernetes ?
Thanks.
Here is my understanding. I'm pretty new to both ACI and Kubernetes, so treat this as a suggestions and not a definitive answers 🙂.
Azure Container Instances is a quick, easy and cheap way to run a single-instance of a container in Azure. However, it doesn't scale very well on its own (it can scale up, but not out, and not automatically..), and it lacks the many container-orchestration features that kubernetes offers.
Kubernetes offers a lot more, such as zero-downtime deployments, scaling out with multiple replicates, and many more features. It is also a lot more complex, costs more, and takes much longer to set up.
I think ACI is a bit too simple to meet your use-case.
I'm looking for a PaaS solution and lately I've been looking into Pivotal Cloud Foundry and OpenShift Origin, trying to compare them.
And honestly, it feels like both offer pretty much the same functionality, to the point where I don't really see a thing, that is truly specific to one of them.
They achieve different things differently, but the functionality remains the same.
The biggest difference seems to be the runtimes these technologies use, as OpenShift uses Kubernetes and PCF uses Diego, and PCF also has it's own container solution.
So here comes my question. What are the differences?
Is there a killer feature in one of them that I'm missing?
As I know, Google's Kubernetes is based on Google's Borg; however, it seems like Borg is larger than Kubernetes. My understanding is that Borg is a large system containing a sub-system like Kubernetes and its own containers like Docker.
So, I would like to know:
1) In term of containers cluster management, what's the key difference between Borg (sub-system inside) and Kubernetes?
2) In term of container technology, what's the key difference between Borg (sub-system inside) and Docker?
I have no 'inside' knowledge of Borg so this answer is based only on what Google themselves have published here. For much greater detail, you should look into that paper. Section 8 makes specific reference to Kubernetes and is the basis of this answer (along with Kubernetes own docs):
1) Key differences:
Borg groups work by 'job'; Kubernetes adds 'labels' for greater flexibility.
Borg uses an IP-per-machine design; Kubernetes uses a network-per-machine and IP-per-Pod design to allow late-binding of ports (letting developers choose ports, not the infrastructure).
Borg's API seems to be extensive and rich, but with a steep learning curve; Kubernetes APIs are presumably simpler. At least, for someone who hasn't worked with Borg, the Kubernetes API seems pretty clean and understandable.
2) Borg seems to use LMCTFY as its container technology. Kubernetes allows the use of Docker or rkt.
Some other obvious differences are the Borg is not open source and not available for use outside of Google, while Kubernetes is both of those things. Borg has been in production use for more than 10 years, while Kubernetes just hit v1.0 in July 2015.
Hope this helps. Check out that Borg paper; it is worth the time to read the whole thing.
Why should I consider using Rocket instead of Docker in our development pipeline. We would like to use docker to create testable containers, but now there is Rocket which pretends to know the same. If we would like to start containerization should we seriously consider Rocket as it seems it is still pretty new?
There is not much information about Rocket, so I'm no clear where it stays now in 2015.
UPDATE: from https://coreos.com/blog/app-container-and-the-open-container-project/
As we participate in OCP, our primary goals are as follows:
Users should be able to package their application once and have it work with any container runtime (like Docker, rkt, Kurma, or Jetpack)
The standard should fulfill the requirements of the most rigorous security and production environments
The standard should be vendor neutral and developed in the open
Rocket is officially dead: https://github.com/rkt/rkt/issues/4024
After acquisition by Red Hot new owner concentrates efforts on https://podman.io/
podman provides rootless containers. Something that Docker strove to get for a long time (according to the below comment, they finally managed).
As with most competitors both have their advantage and disandvantages.
Docker hub offers a public registry where docker images can be pushed and pulled with ease.
There is also now a free registry offered by GitLab! Its really good.
A core issue at the moment is security. Docker now scan their images for security flaws and report on the security status of each image.
With rocket image signatures are cross checked with the signature of the publisher to see if they have been tampered with. This affords a degree of confidence.
For a fuller discussion on security see https://bobcares.com/blog/docker-vs-rkt-rocket/
With regards standards, it seems that OCI (Open Container Initiative) has been adopted by the big players and will pave the way forward for containerisation standatisation.