It looks like you're new here. If you want to get involved, click one of these buttons!
Code: kubectl - Kubernetes command line interface
Date: Current open source framework.
“Kubectl” or “Kube Control” is the command-line interface for Kubernetes, or K8S, the server orchestration framework originally developed by Google. It is used to manage software principally in the cloud, where it can scale up software applications based upon a specification or manifest, as well as via monitoring the live expenditure of computing resources. The command-line interface works on top of these deployment definitions, much like the Unix command-line allows a user to interrogate the state of a runtime system.
K8S’ name and its history at Google are problematic though: “Kubernetes” is the root word or variant of the root from which we get the "Cybernetics" of Norbert Wiener, and an early name of the platform was "Borg", based upon the Star Trek aliens who assimilate/colonize other alien civilizations and boldly announce to them that "resistance is futile”. In addition, the architecture of the platform demarcates "master" nodes that run within a "control pane" and "worker nodes" that host applications and run them. The fundamental unit of the nodes is the “pod,” which is a collection of application container environments running code. Especially with the name of the command-line interface suffixed with -ctl, which is an abbreviation for “control” the K8S platform seems to be a direct embrace of the discipline of cybernetics as “command and control”.
That said, K8S is powerful, and could be seen to facilitate exploratory programming, coding ateliers, and Marxian dreams of allowing proletarian developers to instantly instantiate a technological and productive base that determines how political and cultural bodies are represented. In particular, two powerful features of Kubernetes/kubectl are namespaces and labels, allowing a developer to organize/orchestrate server resources, as the so-called helmsperson.
Labels more specifically allow search-engine-like queries on these resources, so that a developer could summon all components running their app via just a few commands—despite the fact that this app would be built from nodes of worker pods in a vast homogeneous sea of other worker pods.
For example, labels can be used to group pods by application name or release type as demonstrated by Marko Lukša in his Manning guide to K8S, but the labels can be anything. With kubectl, I can create a YAML manifest:
apiVersion: v1 kind: Pod metadata: name: myApp-cloud-001 labels: app: picturebook rel: beta spec: containers: - name: myApp-Container image: myApp-w-nodeJS ports: - containerPort: 8080 ...
And I then can create a cloud cluster, replicating nodes with pods by passing the manifest file above as an argument:
kubectl apply -f pod.myapp.yaml
And then, after K8S has spun up my app and distributed it potentially to multiple pods all automatically, I can summon these pods with a command like the following, specifying which ones I want to fetch via the labels I've defined:
kubectl get po -L app,rel
kubectl get pods -l app=taxes, rel=beta
Or another query using kubectl:
kubectl get pods -l 'app in (picturebook, taxes)' -L app
These searchable labels exemplify inaugural Cybernetics, as “labelling” has been at the center of development of programming after World War II—whenever we speak of variables, identifiers, keywords and code. Because first generation cybernetics formalizes symbolic language within the same cultural and disciplinary space as Lacanian psychoanalysis, so a kubectl label is a use of language becoming absolute and formal and integrated into societal controls. In fact, K8S labels embody applied programming, but also command and control, since the entire lifecycle of their applications is automated through selectors (like in the queries above) on these labels. Note too that, scaling up, scaling down, and restarting pods and containers, a given application never terminates—in true Borg fashion.
At the birth of the Unix computer, if a command to list the file contents of a single computer made the human-computer interface operative, so kubectl has multiplied this system interrogation for thousands of machines simultaneously—as one giant distributed machine. The “power” of the command-line is propagated to kubectl, which can also wrap the operating system command-line in serverless instructions that produce a command result while bypassing runtime systems altogether in some cases**. In effect, in the figure of the software platform K8S, the metaphor of command and control in its specific post-war flavor has been resurrected. But there are many hidden costs of this magic-seeming orchestration across thousands of machines, whether environmental or related to the denial of death and materiality.
As a result, the wealth of critiques of cybernetics, even those from its own age, must be applied to cloud computing. Deleuze and Guattari are helpful here, in offering better metaphors for technology: the notion of the machinic is a critique of the Lacanian signifier-signified relation assumed by the Western labelling subject—while not abandoning technological metaphors. Gilbert Simondon’s work is relevant here too: in the notions of individuation and mechanology, value of technological artifacts in their “aseity” is deferred until interested actors, readers, and cultural laborers productively articulate their interconnections.
As it turns out, one of the lesser known features of K8S is what is called its affinity and anti-affinity definitions, which can be added to a deployment specification or manifest. An affinity definition is a set of numeric values that specify the probability of hardware and system conditions by which containers and pods should group themselves together and reform pod instances when one or more of them has been temporarily terminated to be replaced by other pods. No doubt, this feature is a tool of automation still ultimately tied to command and control. But could the general notion of affinity rather than a helmsperson offer a way out of current K8S metaphors?
** For example, a command to look up a DNS setting on a resource:
kubectl run -it srvlookup --image=tutum/dnsutils --rm --restart=Never -- dig SRV taxes.default.svc.cluster.local, after Lukša.
rm removes the server image, but the command still produces an output.