Kubernetes 101

The simplest way to experience Kubernetes is to run an nginx container and then use kubectl to manage it. Kubernetes offers a command similar to docker run called kubectl run, which conveniently creates a container (actually, it creates a Pod managed by a deployment):

$ kubectl run --image=nginx:alpine nginx-app --port=80
deployment "nginx-app" created
$ kubectl get pods
NAME                         READY     STATUS    RESTARTS   AGE
nginx-app-4028413181-cnt1i   1/1       Running   0          52s

Once the container is up and running, you can operate it using kubectl commands, such as:

kubectl get - similar to docker ps, to query the list of resources
kubectl describe - similar to docker inspect, to get detailed information about a resource
kubectl logs - similar to docker logs, to get container logs
kubectl exec - similar to docker exec, to execute a command inside a container

$ kubectl get pods
...
$ kubectl exec nginx-app-4028413181-cnt1i -- ps aux
...
$ kubectl describe pod nginx-app-4028413181-cnt1i
...
$ curl http://172.17.0.3
...
$ kubectl logs nginx-app-4028413181-cnt1i
...

Defining a Pod with yaml

Above, we launched our first Pod using kubectl run, but kubectl run does not support all functionalities. In Kubernetes, it's more common to define resources using yaml files and to create resources with kubectl create -f file.yaml. For example, a simple nginx Pod could be defined as:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    ports:
    - containerPort: 80

Previously mentioned, kubectl run doesn't directly create a Pod; it first creates a Deployment resource (replicas=1), after which the associated ReplicaSet automatically creates a Pod. This is equivalent to the following configuration:

...

Using Volume

Pod lifecycles are typically short, and a new Pod is created to replace it as soon as any issues occur. What about data generated by containers? It vanishes along with the Pod's demise. Volumes exist for the sole purpose of persisting container data. For instance, you could specify a hostPath for a redis container to store data:

...

Kubernetes volumes support various plugins, allowing selection based on actual needs:

emptyDir
hostPath
gcePersistentDisk
awsElasticBlockStore
nfs
iscsi
flocker
glusterfs
rbd
cephfs
gitRepo
secret
persistentVolumeClaim
downwardAPI
azureFileVolume
vsphereVolume

Using Service

Although we've created a Pod, in Kubernetes, it's ill-advised to interact directly with a Pod's IP address since it changes with Pod restarts. So how do we access the services offered by these Pods? By using Service. Service provides a unified entry for a set of Pods (selected via labels), offering load balancing and automatic service discovery. For example, you can create a service for the previous nginx-app:

$ kubectl expose deployment nginx-app --port=80 --target-port=80 --type=NodePort
service "nginx-app" exposed
$ kubectl describe service nginx-app
...

Now, inside the cluster, nginx-app can be accessed via http://10.0.0.66 and http://node-ip:30772. From outside the cluster, only http://node-ip:30772 is accessible.

Diving into Kubernetes: An Introductory Guide

Eager to get hands-on with Kubernetes? The easiest start is running an nginx container, then bossing it around with kubectl. Picture Kubernetes' kubectl run like a beefed-up docker run—it spins up a container, but behind the scenes, it's conjuring a Pod managed by a deployment:

$ kubectl run --image=nginx:alpine nginx-app --port=80
deployment "nginx-app" created
$ kubectl get pods
...

After our container hits the 'Running' stage, it's fair game for kubectl commands. Notable moves include:

kubectl get - peek at resources, kind of like peering at your running processes with docker ps
kubectl describe - snag that coveted detailed resource intel, much like docker inspect
kubectl logs - reel in those container logs, a la docker logs
kubectl exec - drop commands into your container, reminiscent of docker exec

$ kubectl get pods
...
$ kubectl exec nginx-app-4028413181-cnt1i -- ps aux
...
$ kubectl describe pod nginx-app-4028413181-cnt1i
...
$ curl http://172.17.0.3
...
$ kubectl logs nginx-app-4028413181-cnt1i
...

Crafting a Pod with yaml

We kicked things off with kubectl run, which is easy but not all-powerful. For the full spectrum of control, yaml files are Kubernetes' blueprint of choice, paired with a kubectl create -f file.yaml incantation:

...

Earlier we learned kubectl run isn't a straight shot to a Pod; it's more like a detour through Deployment Town. Your command shapes a Deployment (replicas=1), which then commands a ReplicaSet to whip up your Pod, echoing this yaml setup:

...

Embracing Volumes

Pods live fast and die young, any hiccup and poof, it's clone time. What of your container's precious data? Without volumes, it's dust. Enter volumes, your data's immortality charm. Say you're running redis—just anchor it with a hostPath, and your data's grounded:

...

Got a specific storage fancy? Kubernetes has volume plugins aplenty to satisfy your whims:

emptyDir
hostPath
gcePersistentDisk
awsElasticBlockStore
nfs
iscsi
flocker
glusterfs
rbd
cephfs
gitRepo
secret
persistentVolumeClaim
downwardAPI
azureFileVolume
vsphereVolume

Harnessing Service

Crafting a Pod is a win, but in Kubernetes, nodding to a Pod's IP for chit-chats is a no-no—they're the chameleons of the IP world. Craving some consistency in your network? Service is your ticket. It rallies a pod posse (huddled under label umbrellas) providing a stalwart gateway, load balancing heroes, and service discovery sorcery. Need to expose nginx-app to adoring fans? Deploy a service:

$ kubectl expose deployment nginx-app --port=80 --target-port=80 --type=NodePort
service "nginx-app" exposed
$ kubectl describe service nginx-app
...

Inside the cluster, http://10.0.0.66 or http://node-ip:30772 are your golden tickets to nginx-app. From the great beyond? http://node-ip:30772 is your sole portal.

上一页Kubernetes Concepts 下一页Kubernetes 201

最后更新于11个月前