alberteinstein

Whether it's a gimmick or not, the fact that there is a need/demand for such products is a scary one. People want to wear bullet proof fashionable clothing since they are not sure when they'll be shot at? It didn't matter how ugly bullet proof vests are since those who wore them didn't care how they looked, they just wanted to stay alive. This is really scary.

The system with worst or no abort procedures is the Space Shuttle. Earlier versions had ejection seats, but they got rid of that. Imagine if they had Soyuz like capsule which can popped off. Both Challenger and Discovery crew would have been ok. No wonder they discontinued that program.

One of the authors here: You can open GraphiQL on any GraphQL endpoint using graphqurl:

  gq https://api.yelp.com/v3/graphql -H "Authorization: Bearer ACCESS_TOKEN" -H "Content-Type: application/graphql" -i

Please do reach out to us on discord [1] if you have any questions whatsoever :)

[1]: https://discord.gg/vBPpJkS

The GraphQL Engine is written in Haskell, the Console in JavaScript and the CLI in Go. The repo contains all the three components. :) (I am one of the maintainers)

We built this tool to bootstrap vendor specific declarative templates (Google Cloud Deployment Manager Template [1], Azure Resource Manager Template [2] etc.) that provisions a Kuberentes cluster (and disks), because writing them by hand is a pain. Kubeformation can read a spec file (common for all vendors) and generate these templates.

[1] https://cloud.google.com/deployment-manager/ [2] https://docs.microsoft.com/en-us/azure/azure-resource-manage...

Co-author here. We built this tool to bootstrap vendor specific declarative templates (Google Cloud Deployment Manager Template [1], Azure Resource Manager Template [2] etc.) that provisions a Kuberentes cluster (and disks), because writing them by hand is a pain.

[1] https://cloud.google.com/deployment-manager/ [2] https://docs.microsoft.com/en-us/azure/azure-resource-manage...

Indeed! And when the logs show nothing being wrong? All k8s components were reporting that everything is fine.

Using netstat/lsof/tcp_dump from inside the containers did not help unfortunately. Eventual next step was to check nodes and kernel logs revealed the issue rightaway.

Spacemacs in Vim mode: best of both worlds

Yes, ksync and telepresence lets you develop on k8s cluster as if you were doing on the local system. Haven't looked at forge yet.

These tools are really useful when you're writing code dependent on other components or features on the cluster (like DNS). They save you a lot of port forward, environment variable hassles. Gives high velocity development flows, which were quite long build-push-deploy workflows earlier.

Gitkube is simpler since everything is contained in the cluster itself. Image is built and rolled out from within the cluster right now. (gitkube contributor here)

Kubernetes will definitely be an overkill if you run only one container. But, if your application follows microservice architecture and have multiple containers, Kubernetes is the best solution to run them.

Kubernetes architecture is entirely different from that of Docker Swarm.

A Kubernetes Service object [1] can load balance traffic to various Kubernetes Pods (think containers) [2] as defined by it's " pod selectors". It can choose to direct traffic only to running containers.

[1] https://kubernetes.io/docs/concepts/services-networking/serv... [2] https://kubernetes.io/docs/concepts/workloads/pods/pod/

Yes, it does. Kubernetes can perform rolling updates [1].

One scenario is that when you rollout a new version, the old container will only be killed when new one is up and running. If there are many replicas running, Kubernetes will replace them with new versions one by one. And all of this behaviour is highly configurable.

[1] https://kubernetes.io/docs/tutorials/kubernetes-basics/updat...

If you use container orchestration platforms like Kubernetes, this is not required, as restarts load balancing etc. are handled by the orchestrator.

True, optimising with a multi-stage build after `yarn build` should do it.

This doesn't happen on Kubernetes. The Pod stays in ContainerCreating state unless the entire image is pulled. We are running some Java containers which are >2GB and apart from the time it takes to start-up on a fresh node, everything is fine.

This adds an un-necessary dependency between services. Team working on service A would need to coordinate with team working on service B to keep same layers. The contract should be to keep the image size as small as possible, and teams can work independently.

Also, python:3.6 doesn't always mean the same layers, since it could be rebuilt with entirely different layers with same tag, unless FROM is locked to a particular layer.

#4: Another motivation for using Alpine is to have a shell available so that quick debugging is possible if something goes wrong. For e.g. use ping to see if DNS lookups are happening in a Kubernetes cluster.

When a container is scheduled to a node in Kubernetes, if the image is already available, it takes only ~2s for it to be up and running. But, if it is not present on a node and the image is of 2GB, the download speed is the rate limiting factor, taking start up times well beyond 2 seconds. And in a multi node environment where you do scaling up and down or maybe autoscale, new nodes could come up a lot. So, Leaner images are always better.

Thanks, will try this out and update.

Having two different versions is not an issue, tools like GVM helps in managing them. Docker helps in handling this easily without any extra tools. But, if something is built with a version, it cannot be easily changed without thorough testing.

For e.g. when Kubernetes was built with Go 1.8 instead of 1.7, emptyDir teardown path was broken due to the change in behavior of os.Rename in Go 1.8 [1]. This bug caused other issues like the one with minikube [2] and they had to rebuild with Go 1.7 and update new binaries for already released v0.20.0

[1] https://github.com/kubernetes/kubernetes/issues/43534#issuec... [2] https://github.com/kubernetes/minikube/issues/1630#issuecomm...

Thanks! Will try, test and update regarding points 1,2,3. My use case required ca certs but I'll mention the scratch alternative too.

Sorry about that, we have deprecated local feature, but yeah docs lag behind.

Please login to https://dashboard.hasura.io and create a free trial project.