Kubernetes学习笔记（二）：Pod、标签、注解

时间 2020-05-21

标签 kubernetes 学习笔记 pod 标签注解繁體版

原文原文链接

pod与容器

一个pod是一组紧密相关的容器，它们老是一块儿运行在同一个节点上，以及同一个LInux命名空间中。
每一个pod拥有本身的ip，包含若干个容器。pod分布在不一样的节点上。html

为何须要pod

为何须要pod，而不是直接使用容器：
由于容器被设计为只运行一个进程，因为不可以将多个进程汇集在一个单独的容器中，就须要另外一种结构将容器绑定在一块儿，并将它们做为一个单元管理，这就是pod的根本原理。node

pod中容器的隔离共享

在同一个pod中，多个容器有些资源是共享的，有些是隔离的。
同一个pod中的全部容器都运行在相同的network、UTS、IPC空间下。因此它们共享网络接口、主机名，能够经过IPC互相通讯。
同一个pod中的全部容器的文件系统是隔离的。nginx

什么时候在pod中使用多个容器

它们是不是一个总体？
它们是否须要在一块儿运行？
它们是否要一块儿扩缩容？

运行pod

pod和其余Kubernetes资源一般都是经过向Kubernetes REST API提供JSON或者YAML文件来建立的。
咱们使用nginx镜像建立一个pod。git

nginx.yaml

apiVersion: v1	# API版本
kind: Pod	# 资源类型
metadata:
  name: nginx	# pod的名称
spec: 
  containers: 
    - image: nginx	# 建立容器所用的镜像地址
      name: nginx	# 容器名称
      ports:
        - containerPort: 80	# 应用监听的端口
          protocol: TCP

这里只给出了一个简单的描述文件，大部分字段没有给出。docker

kubectl explain

kubectl explain至关于一个文档，能够查看每一个API对象支持哪些字段。json

-> [root@kube0.vm] [~] k explain pod
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion	<string>
     APIVersion defines the versioned schema of this representation of an
     object. Servers should convert recognized schemas to the latest internal
     value, and may reject unrecognized values. More info:
     https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

   kind	<string>
     Kind is a string value representing the REST resource this object
.................

kubectl create

使用kubectl create建立podapi

-> [root@kube0.vm] [~] k create -f nginx.yaml
pod/nginx created

kubectl get

使用kubectl get查看，指定-o wide查看更多字段网络

-> [root@kube0.vm] [~] k get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          11s

-> [root@kube0.vm] [~] k get -o wide pods 
NAME    READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          22s   10.244.2.6   kube2.vm   <none>           <none>

完整定义

使用kubectl get -o yaml或者kubectl get -o json查看pod的完整定义。这个定义包含如下三大部分：app

metadata：包括名称、命名空间、标签和关于该pod的其余信息
spec：包含pod内容的实际说明，如容器、卷等
status：包含运行中pod的当前信息，如pod IP、宿主机IP、每一个容器的描述和状态

-> [root@kube0.vm] [~] k get -o yaml pod/nginx
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: "2020-05-20T00:32:43Z"
  name: nginx
  namespace: default
  resourceVersion: "109529"
  selfLink: /api/v1/namespaces/default/pods/nginx
  uid: a2b83142-9f17-4cfe-a9ac-04f57de82053
spec:
  containers:
  - image: nginx
    imagePullPolicy: Always
    name: nginx
    ports:
    - containerPort: 80
      protocol: TCP
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-vlqvz
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: kube2.vm
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: default-token-vlqvz
    secret:
      defaultMode: 420
      secretName: default-token-vlqvz
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: "2020-05-20T02:46:50Z"
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: "2020-05-20T02:46:57Z"
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: "2020-05-20T02:46:57Z"
    status: "True"
    type: ContainersReady
  - lastProbeTime: null
    lastTransitionTime: "2020-05-20T00:32:43Z"
    status: "True"
    type: PodScheduled
  containerStatuses:
  - containerID: docker://b63c67379def88a5253e8da543655552185f14e6eb962926d65ec74c5a7ab6f7
    image: nginx:latest
    imageID: docker-pullable://nginx@sha256:30dfa439718a17baafefadf16c5e7c9d0a1cde97b4fd84f63b69e13513be7097
    lastState: {}
    name: nginx
    ready: true
    restartCount: 0
    started: true
    state:
      running:
        startedAt: "2020-05-20T02:46:57Z"
  hostIP: 192.168.199.212
  phase: Running
  podIP: 10.244.2.6
  podIPs:
  - ip: 10.244.2.6
  qosClass: BestEffort
  startTime: "2020-05-20T02:46:50Z"

kubectl logs

kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER] [options]
使用kubectl logs能够查看pod中的日志。若是pod中有多个容器，可使用-c <container>指定容器。好比：curl

-> [root@kube0.vm] [~] k logs nginx -c nginx -f

kubectl port-forward

kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N]
pod已经运行了，那如何向集群中的pod发出请求呢。咱们经过kubectl port-forward命令，将本地端口映射到指定pod的端口上。

窗口1：运行kubectl port-forward

-> [root@kube0.vm] [~] k port-forward nginx 8000:80
Forwarding from 127.0.0.1:8000 -> 80
Forwarding from [::1]:8000 -> 80
Handling connection for 8000 # curl请求发出后出现

窗口2：运行kubectl logs

-> [root@kube0.vm] [~] k logs nginx -f
127.0.0.1 - - [20/May/2020:03:19:50 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-" # curl请求发出后出现

窗口3：curl发出请求

-> [root@kube0.vm] [~] curl http://localhost:8000
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
........

标签选择器

标签选择器可使咱们获取具备特定标签的pod子集。规则经过-l选项指定，多个用逗号分隔。

选择规则

key：选择存在标签key的
!key：选择不存在标签key的
key=value：key存在而且值等于value
key!= value：选择"key=value"的补集。也就存在key而且不等value的，或者不存在key的。
key in (value1,value2)：key存在且值为value1或者value2
key notin (value1,value2)：key存在且值不为value1和value2

实操

准备几个不一样label的pod：

-> [root@kube0.vm] [~] k get po --show-labels
NAME             READY   STATUS    RESTARTS   AGE     LABELS
nginx-labels     1/1     Running   0          40m     app=order,env=prod
nginx-labels-1   1/1     Running   0          9m42s   env=debug
nginx-labels-2   1/1     Running   0          8m8s    app=user,env=dev

app

-> [root@kube0.vm] [~] k get po --show-labels -l app
NAME             READY   STATUS    RESTARTS   AGE   LABELS
nginx-labels     1/1     Running   0          50m   app=order,env=prod
nginx-labels-2   1/1     Running   0          18m   app=user,env=dev

!app

-> [root@kube0.vm] [~] k get po --show-labels -l '!app'
NAME             READY   STATUS    RESTARTS   AGE   LABELS
nginx-labels-1   1/1     Running   0          20m   env=debug

app=order

-> [root@kube0.vm] [~] k get po --show-labels -l app=order
NAME           READY   STATUS    RESTARTS   AGE   LABELS
nginx-labels   1/1     Running   0          77m   app=order,env=prod

app!=order

-> [root@kube0.vm] [~] k get po --show-labels -l app!=order
NAME             READY   STATUS    RESTARTS   AGE   LABELS
nginx-labels-1   1/1     Running   0          46m   env=debug
nginx-labels-2   1/1     Running   0          45m   app=user,env=dev

env in (dev,prod)

-> [root@kube0.vm] [~] k get po --show-labels -l 'env in (dev,prod)'
NAME             READY   STATUS    RESTARTS   AGE   LABELS
nginx-labels     1/1     Running   0          78m   app=order,env=prod
nginx-labels-2   1/1     Running   0          46m   app=user,env=dev

env notin (prod)

-> [root@kube0.vm] [~] k get po --show-labels -l 'env notin (prod)'
NAME             READY   STATUS    RESTARTS   AGE   LABELS
nginx-labels-1   1/1     Running   0          48m   env=debug
nginx-labels-2   1/1     Running   0          46m   app=user,env=dev

使用标签选择器约束pod调度

其核心思想是，为工做节点（node）打上标签，好比地区、机房、CPU密集、IO密集等。而后在建立pod的描述文件时指定对应标签，调度器就会将pod调度到符合标签选择器规则的工做节点上。

如今假设一个场景：须要将新建的pod调度到IO密集的工做节点上。

给node打标签

-> [root@kube0.vm] [~] k label node kube1.vm io=true
node/kube1.vm labeled

-> [root@kube0.vm] [~] k get node -L io
NAME       STATUS   ROLES    AGE   VERSION   IO
kube0.vm   Ready    master   19h   v1.17.3
kube1.vm   Ready    <none>   19h   v1.17.3   true
kube2.vm   Ready    <none>   19h   v1.17.3

nginx-io.yaml

带有选择器的yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx-io
spec:
  nodeSelector: # 选择器
    io: "true"
  containers:
    - image: nginx
      name: nginx

建立pod，查看结果确实是运行在kube1.vm上。

-> [root@kube0.vm] [~] k create -f nginx-io.yaml
pod/nginx-io created

-> [root@kube0.vm] [~] k get pod -o wide
NAME             READY   STATUS    RESTARTS   AGE    IP            NODE       NOMINATED NODE   READINESS GATES
nginx-io         1/1     Running   0          42s    10.244.1.7    kube1.vm   <none>           <none>

注解

注解也是键值对，与标签相似，但注解并不用于标识和选择对象。
注解主要为Pod和其余API对象添加说明，以便每一个使用集群的人能够快速查找与对象有关的信息。

kubectl annotate

使用kubectl annotate为pod添加注解，一样修改已存在的注解须要指定--overwrite

-> [root@kube0.vm] [~] k annotate po nginx-io my.com/someannotation="123"
pod/nginx-io annotated

查看

-> [root@kube0.vm] [~] k describe po nginx-io
..........
Annotations:  my.com/someannotation: 123
..........

命名空间

简单讲，命名空间为Pod等资源提供了做用域，在不一样命名空间内的资源名称能够相同。
咱们以前一导致用的是默认命名空间：default，以前的 nginx-xxx 这些pod都位于这个命名空间。

查看命名空间

-> [root@kube0.vm] [~] k get ns #ns是namespace缩写
NAME              STATUS   AGE
default           Active   21h
kube-node-lease   Active   21h
kube-public       Active   21h
kube-system       Active   21h

kubectl create namespace

使用kubectl create建立一个namespace，固然也能够写一个描述文件建立（麻烦了点）。

-> [root@kube0.vm] [~] k create ns test
namespace/test created

-> [root@kube0.vm] [~] k get ns -o wide
NAME              STATUS   AGE
........
test              Active   94s

为资源指定命名空间

能够在描述文件的metadata下添加一个字段namespace: test，或者在命令行的时候指定kubectl create -f xxx.yaml -n test。

命名空间的误解

首先要明确的是：命名空间并不提供对正在运行的对象的任何隔离。
举个例子：两个pod并不会由于在不一样的命名空间而没法进行网络通讯，是否能够通讯不取决于命名空间，而取决于网络解决方案。

kubectl delete

按名字删除pod

k delete po nginx-io

使用标签选择器删除

k delete po -l app

删除全部pod

k delete po --all

删除命名空间

k delete ns test

删除命名空间（几乎）全部资源

第一个 all 表示当前命名空间全部资源类型，第二个 --all 表示全部资源实例。

k delete all --all

小结

如何决定多个容器是否应该放在一个pod
经过提交描述文件建立API对象
使用标签组织API对象
经过标签选择器调度pod
命名空间使不一样团队很方便的使用同一个集群
一些命令：create、get、delete、label、annotate、port-forward、describe、logs、explain