k8s之pod管理

一.Pod管理(命令行形式)

Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip
一个pod类似一个豌豆荚(共享池)，包含一个或多个容器（通常是docker），多个容器间共享IPC、Network和UTC namespace
kubectl命令

(一)创建Pod应用

1.准备

server1 作为本地仓库
cd /root/harbor
docker-compose start
docker-compose ps  #本地仓库已运行

server2 master
kubectl get node
kubectl get ns
kubectl get pod -n kube-system 
kubectl describe pod coredns-7f89b7bc75-5sxmb -n kube-system
# 节点没有网关时可能会报错
# 如果某个pod报错,可以直接删掉,控制器会重新建,随时创建/回收

2.创建pod

server2 master,不做调度
kubectl run -h #帮助
kubectl run app --image=myapp:v1  #已经指定本地仓库,保证镜像在仓库中;也可以指定namespace,默认在default
kubectl run demo --image=busyboxplus -it  #ctrl+p+q打入后台

kubectl get pod  #查看pod
kubectl get pod -o wide
kubectl attach demo -it  #当pod内有多个容器时,加-c指定容器;再次进入;集群内部任意节点可以访问Pod，但集群外部无法直接访问

kubectl delete pod app  #删除pod

3.创建控制器

kubectl create deployment -h  #帮助
kubectl create deployment nginx --image=myapp:v1
kubectl get all

kubectl delete pod nginx-67f9d9c97f-pbs77  #删除后,控制器deployment让rs自动重建

# Pod扩容与缩容
kubectl scale deployment --replicas=2 nginx
kubectl get pod -o wide
# 回收时先回收运行时间短的

(二)微服务

service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务

# 创建service
kubectl expose -h
kubectl expose deployment nginx --port=80
kubectl get svc
kubectl describe svc nginx
# 此时pod客户端可以通过service的名称访问后端的两个Pod
# 1.ClusterIP: 默认类型，自动分配一个仅集群内部可以访问的虚拟IP

kubectl scale deployment --replicas=6 nginx  #扩容;自动实现负载均衡

# 2.使用NodePort类型暴露端口，让外部客户端访问Pod
kubectl edit svc nginx
type: NodePort

kubectl expose deployment nginx --port=80 --type=NodePort	 #也可以在创建service时指定类型

# NodePort: 在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过  NodeIP:NodePort 来访问该服务
[root@xd Desktop]# curl 172.25.2.2:31977/hostname.html  #真机访问测试

(三)利用控制器更新

# 更新pod镜像
kubectl set image -h
kubectl set image deployment nginx myapp=myapp:v2  #也可以更新pod内的多个容器版本

# 回滚
kubectl rollout history deployment nginx  #查看历史版本
kubectl rollout undo deployment nginx --to-revision=1  #回滚版本

二.资源清单(yml文件形式)

资源清单参数1
资源清单参数2
资源清单参数3
资源清单参数4

(一)参考帮助自己写

/root/.kube/config  #apiVersion: v1 存放地址
kubectl api-versions  #查看所有的api

kubectl explain pod.spec.containers   #清单帮助,一层层往下看

kubectl delete deployments.apps nginx  #删除之前创建的
kubectl delete svc nginx

# 1.pod
vim podtest.yml
apiVersion: v1  #指明api资源属于哪个群组和版本，同一个组可以有多个版本
kind: Pod  #标记创建的资源类型，k8s主要支持以下资源类别:Pod,ReplicaSet,Deployment,StatefulSet,DaemonSet,Job,Cronjob
metadata:  #元数据
  name: nginx  #对像名称
  namespace: default  #对象属于哪个命名空间
spec:  #定义目标资源的期望状态
  containers:
  - name: nginx
    image: myapp:v1
    imagePullPolicy: IfNotPresent
   
kubectl apply -f podtest.yml  #创建
kubectl delete -f podtest.yml  #删除

# 2.Deployment
vim pod.yml  #更新只需更改文件,重新生成
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - name: nginx
        image: myapp:v1
        imagePullPolicy: IfNotPresent  #拉取镜像策略,本地有就不拉取

kubectl apply -f pod.yml
kubectl delete -f pod.yml

(二)将运行的pod输出成yaml

kubectl create deployment nginx --image=myapp:v1
kubectl get pod nginx-67f9d9c97f-6vcck -o yaml | less

(三)优化

kubectl explain deployments.spec.template.spec  #标签选择帮助

vim pod.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      #nodeSelector:
      #  kubernetes.io/hostname: server4  #这种也可以
      nodeName: server3  #增加标签选择器
      #hostNetwork: true  #使用主机网络,注意端口不能冲突
      containers:
      - name: nginx
        image: myapp:v1
        imagePullPolicy: IfNotPresent
        resources:
          requests:
            cpu: 100m  #最小限制;十分之一cpu资源,也可以写成0.1
            memory: 100Mi
          limits:  #上限,超出被控制器杀死
            cpu: 0.5
            memory: 512Mi
       - #这里也可以定义多个容器

kubectl apply -f pod.yml
kubectl get pod
kubectl describe pod nginx-64f65775c9-x56k9
kubectl logs nginx-9d59c76fb-tczk9 nginx  #日志查看


(四)标签的使用
主要在控制器中使用,可以在节点上或pod打标签

kubectl get pod --show-labels  #查看标签
kubectl label pod nginx-9d59c76fb-tczk9 version=v1  #打标签
kubectl label pod nginx-9d59c76fb-tczk9 version=v2  #更改标签 
kubectl get pod -l version  #过滤包含version的标签
kubectl get pod -L version
也可以通过在yaml文件中增加标签选择器

三.Pod生命周期

1.registry.aliyuncs.com/google_containers/pause #基础环境,容器环境初始化
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器
2.init 容器与普通的容器非常像，除了如下两点：
(1)它们总是运行到完成。
(2)Init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行
3.如果 Pod 的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。然而，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动
(一)init容器
Init 容器能做什么？
1.Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
2.Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
3.应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
4.Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
5.由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动

使用启动探测器保护慢启动容器

vim init.yml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: myapp:v1
  initContainers:
  - name: init-myservice
    image: busyboxplus
    command: ['sh', '-c', "until nslookup myservice.default.svc.cluster.local; do echo waiting for myservice; sleep 2; done"]

vim service.yml 
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80\
    
kubectl apply -f init.yml

kubectl create -f service.yml # initContainers检测机制检测到myservice.default.svc.cluster.local,才会run


(二)探针与普通容器
在整个Pod生命周期内,先定义探测位置,根据位置选取处理程序
探针
重启策略:PodSpec 中有一个 restartPolicy 字段，可能的值为 Always、OnFailure 和 Never.默认为 Always
官网参考
1.定义存活命令

vim live.yml
apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: busyboxplus
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600
    livenessProbe:
      exec:
        command:
        - cat
        - /tmp/healthy
      initialDelaySeconds: 5  #在执行第一次探测前应该等待 5 秒
      periodSeconds: 5  #每 5 秒执行一次存活探测

kubectl apply -f live.yml
kubectl get pod

2.定义就绪 存活探测器

apiVersion: v1
kind: Pod
metadata:
  labels:
    test: liveness
  name: liveness-exec
spec:
  containers:
  - name: liveness
    image: myapp:v1
    livenessProbe:  #存活
      tcpSocket:
        port: 80
        #port: 8080  #当我们定义一个错误的端口时,一直重启pod
      initialDelaySeconds: 2
      periodSeconds: 3
    readinessProbe:  #就绪
      httpGet:
        path: /test.html
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 3

(三)Pod 的生命
(1)一般Pod 不会消失，直到人为销毁他们，这可能是一个人或控制器。
(2)建议创建适当的控制器来创建 Pod，而不是直接自己创建 Pod。因为单独的 Pod 在机器故障的情况下没有办法自动复原，而控制器却可以。
(3)三种可用的控制器：
1.使用 Job 运行预期会终止的 Pod，例如批量计算。Job 仅适用于重启策略为 OnFailure 或 Never 的 Pod。
2.对预期不会终止的 Pod 使用 ReplicationController、ReplicaSet 和 Deployment ，例如 Web 服务器。 ReplicationController 仅适用于具有 restartPolicy 为 Always 的 Pod。
3.提供特定于机器的系统服务，使用 DaemonSet 为每台机器运行一个 Pod