481–490 of 633 posts
https://caleblloyd.com/software/crds-killed-free-kubernetes-...
Basically running etcd in production with reasonable SLA and more than a little bit of data is super hard.
Earlier quoted context omitted.
Namespaces handle most of these issues. A NetworkPolicy can prevent pods within a namespace from initiating or receiving connections from other namespaces, forcing all traffic through an egress gateway (which can have a well-known IP address, but you probably want mTLS which the ingress gateway on the other side can validate; Istio automates this and I believe comes set up for free in GKE.) Namespaces also isolate po…
Namespace are not always well suited to hermetically isolate workloads.
Ultimately, all isolation has its limits. Traditional VMs suffer from hypervisor exploits. Dedicated machines suffer from network-level exploits (network card firmware bugs, ARP floods, malicious BGP "misconfigurations"), etc. You can spend an infinite amount of money while still not bringing the risk to zero, so you have to deploy your resources wisely.
Engineering is about balancing cost and benefit. It's not worth paying a team of CPU engineers to develop a new CPU for you because you're worried about Apache interfering with MySQL; the benefit is near-zero and the cost is astronomical. Similarly, it doesn't make sense to run the two applications in two separate Kubernetes clusters. It's going to cost you thousands of dollars a month in wasted CPUs sitting around, control plane costs, and management, while only protecting you against the very rare case of someone compromising Apache because they found a bug in MySQL that lets them escape the sandbox.
Meanwhile, people are sitting around writing IP whitelists for separate virtual machines because they haven't bothered to read the documentation for Istio or Linkerd which they get for free and actually adds security, observability, and protection against misconfiguration.
Everyone on Hacker News is that 1% with an uncommon workload and an unlimited budget, but 99% of people are going to have a more enjoyable experience by just sharing a pool of machines and enforcing policy at the Kubernetes level.
Good time for people to look into DigitalOcean managed Kubernetes (DOKS). I've been using it since it was in pre-release and its been great so far. Their support has been very responsive as well. https://www.digitalocean.com/products/kubernetes/
Not only are your cluster's administration ports exposed on public addresses with no ability to firewall them, but each node pulls an Admin-level auth token to manage the DigitalOcean account behind the scenes. A single http request made to an internal IP, from within any Docker container running within the cluster, grants the attacker full read/write access and control to the underlying DigitalOcean account. This includes any developer who does so from code deployed into the cluster, giving the developer full access to the business's DigitalOcean account.
Earlier quoted context omitted.
> their position in the market as the second, inferior choice Who's the superior choice? EKS?
EKS feels like a product where Jeff Bezos walked into a room and said "you're all fired if you don't have a Kubersomethings service up in the next two weeks". The team did it and haven't touched it since. The amount of management they make you do is amazing. Need to upgrade the kernel on your nodes? Fill out a five page CloudFormation workflow, and if you copy-pasted anything wrong, your cluster will just randomly wo…
Earlier quoted context omitted.
EKS is $0.10/hour
From my link above: >"The EKS control plane is the easiest to understand with a fixed cost of $0.20 per hour."
https://aws.amazon.com/eks/pricing/ is the up to date page. https://aws.amazon.com/blogs/aws/eks-price-reduction/ is the announcement of the price cut.
Earlier quoted context omitted.
Interesting. As a mid level GCP customer, it won't make a big dent on our bill specifically, but in the end, I'm not sure this pricing move is a smart strategy. With this fixed fee model, the change will barely make a difference (== Google revenue) for the large customers who can spare the money, but will create a significant entry barrier to that side project / super-early stage that considers getting hooked on GCP,…
Thats for me the most frustrating thing with GCP, AWS and Azure. I would never use them as a very early small 3 people startup or for private reasons. There is no billing protection (which could make you very poor very fast) and every service has a certain cost and quality which is just not feasable in the beginning. Even GKE with its free kubernetes master does block a lot of resources on the nodes: https://cloud.go…
You can set billing alerts that will project your monthly budget every hour, and send you an alert when it's projected to be exceeded.
IMHO your claim (that there is an entry cost barrier) is the opposite of reality. AWS and Google have brought incredible power and choice to developers starting at zero initial cost.
Earlier quoted context omitted.
Interesting. As a mid level GCP customer, it won't make a big dent on our bill specifically, but in the end, I'm not sure this pricing move is a smart strategy. With this fixed fee model, the change will barely make a difference (== Google revenue) for the large customers who can spare the money, but will create a significant entry barrier to that side project / super-early stage that considers getting hooked on GCP,…
Thats for me the most frustrating thing with GCP, AWS and Azure. I would never use them as a very early small 3 people startup or for private reasons. There is no billing protection (which could make you very poor very fast) and every service has a certain cost and quality which is just not feasable in the beginning. Even GKE with its free kubernetes master does block a lot of resources on the nodes: https://cloud.go…
Then again, I know enough about AWS and how to control my cost.
Earlier quoted context omitted.
We run lots of small clusters in our projects and identical infrastructure/projects for each of our environments. Multiple clusters lets us easily firewall off communication to compute instances running in our account based on the allocated IP ranges for our various clusters (all our traffic is default-deny and has to be whitelisted). Multiple clusters lets us have a separate cluster for untrusted workloads that have…
Namespaces handle most of these issues. A NetworkPolicy can prevent pods within a namespace from initiating or receiving connections from other namespaces, forcing all traffic through an egress gateway (which can have a well-known IP address, but you probably want mTLS which the ingress gateway on the other side can validate; Istio automates this and I believe comes set up for free in GKE.) Namespaces also isolate po…