第二章pod

标签：保留   内容   describe   使用   修改   logs   新版   linux   ota   

1.介绍pod

pod 是一组并置的容器，代表了Kubernetes的基本构建模块，而实际中并不会单独部署容器，更多的是对一组pod的容器进行部署和操作。然而这并不意味着一个pod总是包含多个容器，　实际上只包含一个单独容器的pod也是非常常见的。一个pod绝对不会跨越多个工作节点

2.为何需要pod

容器被设计为每个容器只运行一个进程(除非进程本身产生子进程)。如果在单个容器中运行多个不相关的进程,那么保持所有进程运行，管理他们的日志等将变的困难。
因此，我们需要让每个进程运行于自己的容器中，而这就是Kubernetes和Docker的期望方式

3.了解pod

由于不能将多个进程聚集在一个单独的容器中，因此我们需要另一种更高级的结构来将容器绑定在一起，并将他们作为一个单元进行管理，而这就是pod需要做的

同一个pod下，所有的容器拥有相同的network，UTS, IPC命名空间，所以这些资源都是共享的非隔离的，而对于文件系统来说，由于来自容器镜像，所以每个容器的文件系统与其他容器完全隔离，但是我们可以通过Volume来共享文件目录

由于一个pod中的容器运行于相同的Network命名空间中，因此他们共享相同的IP地址和端口空间,这意味着同一pod中的容器运行的多个进程不能绑定相同的端口号,否则导致端口冲突，对于不同pod中的容器来说则永远不会出翔端口冲突(IP不同)

同一个Kubernetes集群中的所有pod都在同一个共享网络空间(一个大节点)中，因此每个pod都可以通过其他的Ip地址互相访问，也就是说它们之间没有NAT(网络地址转换)网关,当两个pod之间发送网络数据包时，都会将对方的IP地址看做源IP地址

因此pod之间的通信，非常简单无论两个pod是否在同一个节点上，这些pod都能像在无NAT的平坦网络一样通信就像局域网(LAN)中的计算机一样，每个pod都有自己的ip地址，并且可以通过专门的网络实现pod之间的通信，这个网络通常由额外的软件基于真实链路来实现的

任何情况下都应该优先考虑在单独的pod中运行容器，原因如下:
1.如果将pod分散到多个pod中，那么可以充分利用计算机资源，提高服务负载
2.pod可以很轻松的扩容，如果前端后端在一个pod中，那么最后的结果会导致部署了多个前端和多个后端，通常来说前端和后端具有完全不同的扩缩容要求，所以最好独立扩缩他们

那么何时在pod中使用多个容器呢?有一下考虑

1.它们是否需要一起运行还是可以在不同的主机上运行
2.它们代表的是一个整体还是互相独立的组件
3.它们必须一起进行扩缩容还是可以分别进行

容器不应该包含多个进程，pod也不应该包含多个并不需要运行在同一主机上的容器

4.以YAML或JSON描述文件创建pod

1.YAML 主要部分:

metadata 包括名称， 命名空间， 标签和关于该容器的其他信息
spec 包含pod内容的实际说明，例如pod的容器，卷和其他数据
status 包含运行中的pod的当前信息，例如pod所处的条件，每个容器的描述和状态，以及内部IP和其他基本信息

2.为pod创建一个简单的YAML描述文件

apiVersion: v1
kind: Pod
metadata:
    name: kubia-manual
spec:
    containers:
    - image: luksa/kubia
      name: kubia
      ports:
      - containerPort: 8080
        protocol: TCP
# 资源类型为pod, 名称为kubia-manual, 该pod由基于luksa/kubia镜像的单个容器组成， 此外还给该容器命名为kubia,它监听端口为8080

3.使用kubectl create 来创建pod

kubectl create -f kubia-manual.yaml
# pod/kubia-manual created
kubectl get pods
# kubia-manual                  1/1     Running     0          44s

4.查看pod的完整定义

kubectl get pod kubia-manual -o yaml  返回yaml 格式
kubectl get pod kubia-manual -o json    返回json格式

5.登入容器

kubectl exec -it kubia-manual(pod name) -n default(namespace) /bin/sh

6.查看应用程序日志

kubectl logs kubia-manual(pod name) 获取pod日志
kubectl logs kubia-manual -c kubia 获取pod内容器日志

如果pod被删除，那么日志也会被删除

7.向pod发送请求(基于端口转发)

kubectl port-forward kubia-manual 8888:8080  将本地端口8888映射到pod8080端口
curl localhost:8888
# You've hit kubia-manual

8.使用标签组织pod

1.创建pod时制定标签:

apiVersion: v1
kind: Pod
metadata:
    name: kubia-manual-v2
    labels:
     creation_method: manual
     env: prod
spec:
    containers:
    - image: luksa/kubia
      name: kubia
      ports:
      - containerPort: 8080
        protocol: TCP

kubectl createkubectl create -f kubia-manual-with-labels.yaml 

kubectl get po --show-labels 列出pod还有labels标签
# kubia-manual-v2               1/1     Running     0          14m    creation_method=manual,env=prod
kubectl get po -L creation_method,env
# 过滤制定标签的pod信息

2.为现有的pod添加标签

 kubectl label po kubia-manual creation_method=manual

3.为现有pod修改标签

kubectl label po kubia-manual-v2 env=debug --overwrite

4.通过标签选择器列出pod子集

kubectl get po -l creation_method=manual 筛选标签包含 creation_method=manual  的pod
kubectl get po -l env  筛选包含env标签的所有pod无论其值如何
kubectl get po -l '!env' 筛选没有env标签的pod 一定是单引号，不可以是双引号

kubectl get po -l 'creation_method != manual' 选择带有creation_method标签，并且值不等于manual的pod
kubectl get po -l 'env in (prod, debug)' 选择带有env, 并且职位prod, 或者devel的pod
kubectl get po -l 'env not in (prod, devel)' 选择带有env, 并且值不是prod, 或者devel的pod

5.使用标签来分类工作节点(同pod)

kubectl label node minikube gpu=true 为节点minikube 增加 gpu=true 标签
kubectl get nodes -l gpu=true 筛选gpu=true 的工作节点

6.将pod调度到特定节点

我们只在spec部分添加了一个nodeSelector字段，当我们创建该pod时，调度器将只在包含标签gpu=true的节点中选择

apiVersion: v1
kind: Pod
metadata:
    name: kubia-gpu
spec:
    nodeSelector:
      gpu: "true"
    containers:
    - image: luksa/kubia
      name: kubia

7.金丝雀发布:

金丝雀发布就是在部署新版本时，先让一小部分用户体验新版本，以观察新版本的表现，然后再向所有用户进行推广,防止暴露有问题的版本给过多的用户

9.注解pod

添加注解

kubectl annotate pod kubia-gpu mycompany.com/someanno七a七ion="foo bar" 添加注解
kubectl describe pod kubia-gpu 查看注解
metadata:
  annotations:
    mycompany.com/someannotation: foo bar
  creationTimestamp: "2019-12-11T09:26:10Z"
  name: kubia-gpu
  namespace: default
  resourceVersion: "151364"
  selfLink: /api/v1/namespaces/default/pods/kubia-gpu
  uid: f267f990-1d8c-48f7-bc91-fc0289804b45

10.使用命名空间对资源进行分组

Namespace类似于Linux系统中用户的概念，通过将系统内部的对象分配到不同的Namespace中，形成逻辑上的分，便于不同的分组在共享集群资源的同时还能被分别管理。同一Namespace下的Kubenetes对象的Name必须唯一。

常见的 pod, service, replication controller 和 deployment 等都是属于某一个 namespace 的（默认是 default），而 node, persistent volume，namespace 等资源则不属于任何 namespace。

1.获取命名空间

kubectl get namespace/ns

2.获取制定命名空间下的资源

kubectl get po -n/--namespace default

3.常见的namespace

default：所有未指定Namespace的对象都会被分配在default命名空间。
kube-system：所有由Kubernetes系统创建的资源都处于这个命名空间。
kube-public：此命名空间下的资源可以被所有人访问（包括未认证用户）

4.创建一个名字为custom-namespace的命名空间

apiVersion: v1
kind: Namespace
metadata:
  name: custom-namespace

kubectl create -f custom-namespace.yaml

5.创建资源时分配命名空间的两种办法

1.可以选择在metadata字段中添加一个namespace: custom-namespace
2.kubectl create -f kubia-manual.yaml -n custom-namespace

当有同名的资源时，在对资源进行操作时需要制定命名空间(--namespace 或 -n),如果不指定那么会默认default命名空间

11.停止和移除pod

1.按名称删除pod

kubectl delete po kubia-gpu

2.利用空格分割来删除多个pod

kubectl delete po pod1 pod2

3.使用标签选择器删除pod

kubectl delete po -l aa=bobo
如过该标签下有多个pod，那么将一同删除

4.通过删除整个命名空间来删除pod,命名空间和pod都将删除

kubectl delete ns custom-namespace

5.删除命名空间中的所有pod，但保留命名空间

kubectl delete po --all 删除当前命名空间中的所有pod

6.删除命名空间中的(几乎)所有资源

kubectl delete all --all
删除rc,和pod，以及我们创建的所有service
第一个all制定正在删除的所有资源类型，--all 指定将删除所有资源实例

第二章pod

标签：保留   内容   describe   使用   修改   logs   新版   linux   ota   

原文地址：https://www.cnblogs.com/limengchun/p/12061020.html