61–70 of 80 posts
Earlier quoted context omitted.
It's most likely that even the "CM"s from both providers are actually Virtual Machines running on a hypervisor running on bare metal. You just can't tell and don't need to care (for most workloads).
Yup, you can even SSH to them and poke around yourself.
bundling with (unholy-ly immature) SDN is the most damning things for its adoption. It is thought to be needed for "live migration", but I don't see me needing that anytime soon because we run on virtual machines anyway? Iaas provider is not going away,paying for the cost of SDN now for features that doesn't even exists yet, is insane.
(kubernetes contributor here) SDN isn't required for k8s, what is required is that each Pod (group of containers) get it's own IP address, and that the IP address is routeable in the cluster. In many cases, the easiest way to achieve this is via an SDN, but it is also achievable by programming traditional routers. The reason for wanting an IP address per pod is that it eliminates the need for port mangling, which dra…
Earlier quoted context omitted.
It means "Helmsman" in ancient Greek. Similarly it's related to the word "Governor" e.g: "kubernan" in ancient greek means to steer "kubernetes" is helmsman "gubernare" means to steer or to govern in Latin "gubernator" is "governor" in Latin Which then leads into the modern word "Gubernatorial", et al.
It's also a pun on Borg Cubes.
Does anyone have resources about security/isolation best practices for running multiple applications on Kubernetes (or Mesos or similar)? For instance in a non cloud-native app that runs in VM's, you might have one app per VM and have firewalls between different VM's that don't need to talk to each other. Then if a non-critical app got compromised and an attacker got remote execution or SQL injection or something the…
https://github.com/GoogleCloudPlatform/kubernetes/blob/maste...
which is designed to address some of this.
Earlier quoted context omitted.
(kubernetes contributor here) SDN isn't required for k8s, what is required is that each Pod (group of containers) get it's own IP address, and that the IP address is routeable in the cluster. In many cases, the easiest way to achieve this is via an SDN, but it is also achievable by programming traditional routers. The reason for wanting an IP address per pod is that it eliminates the need for port mangling, which dra…
All applications was already desinged to be port based. I don't see how this would drastically change that.
And ports are different between different replicas of your service, since they're chosen at random during scheduling.
It also makes ACLs and QoS harder to define for the network, since you don't have a clean network identity (e.g IP Address) for each application.
Earlier quoted context omitted.
Calling that categorically incorrect is pretty disingenuous when we have Google engineers who are working on the project saying that it currently supports 100 nodes with ease, and that they /expect/ it to handle more in the (very near) future. It might not be correct for much longer, but if it is the case now, how can you say it's categorically incorrect?
To clarify, this entire statement is categorically incorrect: "The only thing I'll add is that k8s isn't targeting the same scale as Mesos. Their current goal is to support up to 400-500 nodes, max."
Earlier quoted context omitted.
Yup, you can even SSH to them and poke around yourself.
How does that prove it's a VM? How do you know it's not cgroup isolation with a chroot jail? Also known as containers?
Also Amazon bills you for that EC2 instance as any other instance.
Personally I have hard time understanding the benefits of running docker in public cloud, you still run a VM you still pay for that VM. It just one extra abstraction layer which increases complexity of your infrastructure and also reduces performance.
I do understand the benefits of using containers in own data center, when you run it on bare hosts. There's simplicity and and lower costs (because you don't have VM) you have more resources which lets you run more containers than VMs on that host.
Earlier quoted context omitted.
How does that prove it's a VM? How do you know it's not cgroup isolation with a chroot jail? Also known as containers?
Because you're the one setting them up. Basically you run Amazon provided agent on an EC2 instance and ECS will see it as a host for ECS. Also Amazon bills you for that EC2 instance as any other instance. Personally I have hard time understanding the benefits of running docker in public cloud, you still run a VM you still pay for that VM. It just one extra abstraction layer which increases complexity of your infrastr…
Simpler deployment and basically forcing "12-factor", as well as easier development environment setups. Nothing you can't achieve with other tooling, but it's nice to be able to guarantee that your dev environment is identical to your prod.
Worth remembering, Kubernetes was built to Google's needs, and Google runs with a shared network space on any given VM and assigns an entire /24 to the VM running docker. Each container gets one of those addresses. [1] This probably won't work for everyone - be sure to read into the fine grained details before drinking the koolade. They're also at least two build versions behind Docker.[2] [1] https://github.com/Goog…
Indeed the networking requirements of Kubernetes are very different from that of Docker. However, it isn't too difficult to setup a Layer 2 unification overlay network. I've had success with flannel[1], it's pretty easy to set up and supports VxLAN. [1] https://github.com/coreos/flannel
I'd love for someone to explain how Kubernetes compares to Mesos. Every article I find on the subject says they are mutually beneficial, not competitors — that you would typically run Kubernetes as a Mesos framework — yet Kubernetes also seems like it duplicates much of Mesos' functionality on its own.
(disclaimer: i work at Google and was one of the founders of the project) when we were looking at building k8s our mission was to help the world move forwards to a more cloud native approach to development. by cloud native i mean container packaged, dynamically scheduled, micro-services oriented. we figured that in the end our data centers are going to be well suited to run cloud native apps, since they were designed…