I understand that this is a weird question, I've never coded in C, are there any online resources that help me grok OS concepts without a lot of emphasis on hands-on coding assignments.
Is containerd CRI compliant? Kubelet still interacts with cri-containerd which inturn calls containerd. Isn't cri-containerd the dockershim of containerd?
Maybe I'm mixing up things, pls correct me wherever needed.
containerd can serve CRI requests itself. This has been the case since the containerd v1.1.0 release[0], which included the cri "plugin" as an in-process part of the containerd binary. For a while, to keep up the plugin idea, it was in a separate github repo too, but these days it's in the main containerd repo directly[1].
As I understand, dockershim makes docker daemon cri compliant. But dockerd already uses containerd which is cri compliant. So, why can't kubelet directly interact with containerd APIs without dockershim?
The kubelet can talk to containerd's cri endpoint, yes, but there's one additional bit of complexity.
If someone wants to use kubelet + docker so that they can, for example, ssh into a node and type 'docker ps' to see containers, or have something else using the docker api see the containers the kubelet started, that won't work after re-pointing the kubelet from docker to containerd.
The difference here is namespacing[0], but not the linux-kernel-container-namespace, rather the containerd concept by the same name to allow "multi-tenancy" of a single containerd daemon.
In addition, I don't think you could have docker + cri run in the same containerd namespace since they end up using different networking and storage containerd plugins. I think that terminology is right.
So yeah, repointing the kubelet to containerd directly works fine, but it won't be the same thing as running docker containers.
> So, why can't kubelet directly interact with containerd APIs without dockershim?
Each kubelet does its thing through the Container Runtime Interface (CRI), so in a sense it doesn't know what it's running on. If it used containerd's interfaces directly, it wouldn't be possible to substitute in a different option.
For example, there are emerging VM-based approaches like Firecracker and VMware "Project Pacific" (disclosure: I work at VMware).
Apart from Coursera's course "programming languages", are there any other courses which teach interesting concepts from different programming languages instead of zeroing on 1 language.
Instead of compiling Java to Java bytecode which is then executed by the JVM (e.g. Hotspot), you compile it to native machine code/assembly + runtime (Substrate VM). However you loose the cross-platform ability and Java reflections won't work out of the box.
I wouldn't use virtual threads for long-running, compute-heavy tasks, because even when we expose forced preemption, it might not be as efficient as a kernel preemption. Also, if you run a lot of native (non-Java) code that blocks -- or that upcalls back into Java and then blocks -- then the underlying "carrier" kernel thread will be blocked, and if this happens a lot, it can impact other virtual threads that share the same scheduler. So for compute-heavy jobs and for code that blocks in native or upcalls to Java, the platform threads would be more appropriate.
Assume that example.com and foo.example.com have different zone files which in-turn have different ns entries day ns1 and ns2. So if I query for the A record of foo.example.com will it be answered by ns2? If so can I assume that the .com tld server has entries for both example.com and foo.example.com?
So, what are the practical application of zones? I can think of load balancing DNS queries as one.
> So if I query for the A record of foo.example.com will it be answered by ns2?
Yes, if I understand your example correctly.
> If so can I assume that the .com tld server has entries for both example.com and foo.example.com?
No. The .com zone only contains NS records for example.com. The NS records for foo.example.com exist in the example.com zone (and, for consistency, in the foo.example.com zone), but not in the parent .com zone, which knows nothing about any sub-zones.
Zones are used to split DNS data into zones of responsibility. I.e. when you want different administrative entities to have control over different sets of names, you put the names in different zones, served by different name servers controlled by those different administrative entities. If a company would split, say, the HQ and research department into separate subdomains "hq.example.com" and "research.example.com", and if they made those two subdomains into separate zones, each department could have their own name servers and each department’s name server administration team could add and delete server host names in their own zone all day long without risking breaking anything for the other department, and without even involving anyone else.
More practically, the "com" and "net" zones are managed by a different company than, say, the zone for "ibm.com", therefore they are in different zones. Also, the root zone (".") and all the country-specific zones like "se" or "de" are certainly managed by different entities (governments), therefore the root zone is separate from those individual country-specific zones.
