3 ms·
Both of your examples made sense to me, but when you take a step back that sentence doesn't really mean anything without context. A "resource" === "endpoint" i
by cfors 7y ago
Both of your examples made sense to me, but when you take a step back that sentence doesn't really mean anything without context.
A "resource" === "endpoint" in the sense that the endpoint defines where you can define the configuration of a specific resource. They are being specifically vague I am assuming because of the concept of CRDs.
But without that sort of knowledge ("Hey, Kubernetes has a customizable API using custom resources!"), that sentence is rather hard to unpack.
edit: Thinking about it some more I suppose an endpoint is an overloaded term w.r.t. Pod IPs.
- jacques_chester 7y agoWhen you submit a CRD to Kubernetes you get a few things: 1. The CustomResourceDefinition itself, a document that tells Kubernetes "Hey, I have a kind of custom resource I want you to know about". 2. Instances of that custom resource that have been submitted to Kubernetes. "Submitted how?", you ask, which leads to: 3. When you submitted the CRD, Kubernetes automatically created HTTPS endpoints based on the values of the group, kind and version of the CRD. It accepts that custom resource at that endpoint. What makes dealing with CRDs confusing, in my experience, is that "CRD" is used in two senses. One is the actual resource, the actual chunk of YAML submitted to Kubernetes that contains "kind: CustomResourceDefinition". The second sense is to bundle together all the things that can be done with or flow from CRDs. Usually this is where you hear about controllers, operators and so on, but it will still be called "the Foo CRD", even though that's like referring to a 3-tier application as "the Foo table schema".