Kubernetes: Difference between revisions

From Leo's Notes
This page was last edited on 22 November 2018, at 21:47.
Created page with "This article goes over concepts as I try to understand everything about Kubernetes. == Installing == TBW == Concepts == === Pods === A pod is: * A collection of application..."
 
No edit summary
Line 24: Line 24:


Manifest looks like this. A pod can be created by using the {{code|kubectl apply -f pod-manifest.yml}} command to load the manifest.
Manifest looks like this. A pod can be created by using the {{code|kubectl apply -f pod-manifest.yml}} command to load the manifest.
{{highlight|lang=text
{{highlight|lang=text|
apiVersion: v1
apiVersion: v1
kind: Pod
kind: Pod

Revision as of 21:47, 22 November 2018

This article goes over concepts as I try to understand everything about Kubernetes.

Installing

TBW

Concepts

Pods

A pod is:

  • A collection of application containers
  • Guaranteed to land on the same kubernetes cluster machine
  • Shares the same cgroup, IP address, hostname (hence, runs in the same execution environment)

A pod should provide one individual component of an application that can:

  • Be scaled independently of all other components in the application (eg. Database with respect to the frontend web server)
  • Work even if placed (ie. orchestrated) on a different machine
In general, the right question to ask yourself when designing Pods is, “Will these containers work correctly if they land on different machines?” If the answer is “no,” a Pod is the correct grouping for the containers. If the answer is “yes,” multiple Pods is probably the correct solution. In the example at the beginning of this chapter, the two containers interact via a local filesystem. It would be impossible for them to operate correctly if the containers were scheduled on different machines.
—Thinking with Pods, Kubernetes: Up and Running

Pods are defined in text file as a manifest. The Kubernetes API server processes the manifest, then stores it in persistent storage (etcd). A scheduler then finds pods that need to be scheduled and deploys the pods on the appropriate resource that satisfies any constraints defined in the manifest.

Creating

Imperative: kubectl run kuard --image=registry/something/something:tag

Manifest looks like this. A pod can be created by using the kubectl apply -f pod-manifest.yml command to load the manifest.

apiVersion: v1
kind: Pod
metadata:
  name: kuard
spec:
  containers:
    - image: gcr.io/kuar-demo/kuard-amd64:1
      name: kuard
      ports:
        - containerPort: 8080
          name: http
          protocol: TCP


See it running using kubectl get pods. Information of pods can be found by running kubectl describe pods pod-name. Pods can be deleted with kubectl delete pods/pod-name, or by passing in the manifest: kubectl delete -f pod-manifest.yml.

Pods that are set for deletion will cease to have new requests sent to it. After a 30 second termination grace period, the pods are then terminated. This extra time allows for the pod to reliably finish active requests.


Questions

  • What is involved in setting up a cluster on multiple VMs?
  • What is the Kubernetes API?
  • What is this persistent storage (etcd)?

See Also

  • Kubernetes: Up & Running