As a developer started his career during the cloud/everything-as-a-service boom, thinking about Kubernates networking gives me anxiety
Knative = Kubernetes Networking++
11–18 of 18 posts
Re: Knative = Kubernetes Networking++
#12> Knative is about to hit v1.0 and become «stable», has a solid community. I'm sorry for the negativity but I'm skeptical about the reliability. AFAIK it still doesn't really address instabilities. Software crashes, hardware fails, power goes out. It is trivial to lose data, and it is trivial to be blissfully unaware that there is a possibility of data loss because when everything's green, things work perfectly fine.…
I am not sure if an event queue is the primary focus of Knative, or at least this particular blog post. This is focusing on the problem of Kubernetes networking, which is honestly pretty useless. By default, a Kubernetes "service" exists to create a single IP address for a group of replicas. You see that your "foo service" is at 10.2.3.4, you open a TCP connection to it, your connection is created to one of the avail…
I normally don't leave "thank you" comments since they clutter up the discussion, but your comment above was particularly valuable to me and I wanted to make sure you knew that. Thank you :-)
Re: Knative = Kubernetes Networking++
#13Its not governed under the CNCF, so really, what Knative equals is Google lock-in.
That seem premature and unfair. KNative has representation from Google, IBM and Redhat, and the steering committee is working on a more inclusive governance structure. (I have no inside knowledge of this - just what I have gleaned from slack ;-) )
[deleted]
Re: Knative = Kubernetes Networking++
#14> Knative is about to hit v1.0 and become «stable», has a solid community. I'm sorry for the negativity but I'm skeptical about the reliability. AFAIK it still doesn't really address instabilities. Software crashes, hardware fails, power goes out. It is trivial to lose data, and it is trivial to be blissfully unaware that there is a possibility of data loss because when everything's green, things work perfectly fine.…
I am not sure if an event queue is the primary focus of Knative, or at least this particular blog post. This is focusing on the problem of Kubernetes networking, which is honestly pretty useless. By default, a Kubernetes "service" exists to create a single IP address for a group of replicas. You see that your "foo service" is at 10.2.3.4, you open a TCP connection to it, your connection is created to one of the avail…
> My personal opinion is that they do too much; if you name your syslog port "grpc" by accident, goodbye traffic! What was supposed to be documentation is now just an undocumented part of the Kubernetes API.
To be fair, a LOT of things in the Kubernetes world can rely on port names. Service and Ingress resources can use them to target ports on pods (or services, in the case of Ingress resources). Port names are responsible for the name of DNS SRV protocol specifiers for headless services as well.
Re: Knative = Kubernetes Networking++
#15> Knative is about to hit v1.0 and become «stable», has a solid community. I'm sorry for the negativity but I'm skeptical about the reliability. AFAIK it still doesn't really address instabilities. Software crashes, hardware fails, power goes out. It is trivial to lose data, and it is trivial to be blissfully unaware that there is a possibility of data loss because when everything's green, things work perfectly fine.…
I am not sure if an event queue is the primary focus of Knative, or at least this particular blog post. This is focusing on the problem of Kubernetes networking, which is honestly pretty useless. By default, a Kubernetes "service" exists to create a single IP address for a group of replicas. You see that your "foo service" is at 10.2.3.4, you open a TCP connection to it, your connection is created to one of the avail…
>The disadvantage is that you have to manually add an Envoy container and minimal config to everything you run, which people apparently hate.
Correct me if I'm wrong, but I think envoy (or istio, at least), uses a mutable admission webhook to inject the sidecar into your pod. This means you never have to enter anything into your pod spec.
Edit: I noticed you pointed this out with istio.
Re: Knative = Kubernetes Networking++
#16Earlier quoted context omitted.
I am not sure if an event queue is the primary focus of Knative, or at least this particular blog post. This is focusing on the problem of Kubernetes networking, which is honestly pretty useless. By default, a Kubernetes "service" exists to create a single IP address for a group of replicas. You see that your "foo service" is at 10.2.3.4, you open a TCP connection to it, your connection is created to one of the avail…
>The disadvantage is that you have to manually add an Envoy container and minimal config to everything you run, which people apparently hate. Correct me if I'm wrong, but I think envoy (or istio, at least), uses a mutable admission webhook to inject the sidecar into your pod. This means you never have to enter anything into your pod spec. Edit: I noticed you pointed this out with istio.
Yeah, Istio is the Kubernetes glue for Envoy. Envoy is just a proxy; it can exist without Kubernetes and as far as I know, knows nothing about it.
Re: Knative = Kubernetes Networking++
#17> Knative is about to hit v1.0 and become «stable», has a solid community. I'm sorry for the negativity but I'm skeptical about the reliability. AFAIK it still doesn't really address instabilities. Software crashes, hardware fails, power goes out. It is trivial to lose data, and it is trivial to be blissfully unaware that there is a possibility of data loss because when everything's green, things work perfectly fine.…
I am not sure if an event queue is the primary focus of Knative, or at least this particular blog post. This is focusing on the problem of Kubernetes networking, which is honestly pretty useless. By default, a Kubernetes "service" exists to create a single IP address for a group of replicas. You see that your "foo service" is at 10.2.3.4, you open a TCP connection to it, your connection is created to one of the avail…
Hi, Knative team member here.
What you're describing with injecting outbound proxies is definitely something that Istio does in service mesh mode. When Knative launched 0.1 over a year ago, we had a pretty hard dependency on Istio. We heard a lot of feedback from users who weren't ready to make that much commitment, and as of 0.3 (last December or so), Knative supports multiple pluggable HTTP routers, including Gloo, Ambassador and Kourier.
If you aren't using Istio in mesh mode, Knative only controls inbound HTTP networking to your container instances, which it uses to implement scale-from-zero, concurrency-based-balancing, and percentage based version rollout. Outbound network is completely unaffected, except that containers may be shut down when they are no longer handing a request.
Re: Knative = Kubernetes Networking++
#18Earlier quoted context omitted.
That seem premature and unfair. KNative has representation from Google, IBM and Redhat, and the steering committee is working on a more inclusive governance structure. (I have no inside knowledge of this - just what I have gleaned from slack ;-) )
What's premature (it has been around for at least a year)? And why is it unfair to ask for open governance from companies other than Google and IBM (redhat is part of IBM)?
Pivotal is also on the steering committee.
Representation is based on contributions to the project, and Google has publicly stated that they look forward to not being a majority on the steering committee (when other companies have exceeded Google's contributions).
There are CNCF projects whose governance is entirely within a single company. I get that there's a great narrative here that "Google doesn't share", but it seems like Google is being held to a higher bar here.