Pod资源管理

特点：
最小部署单元
一组容器的集合
一个Pod中的容器共享网络命令空间
Pod是短暂的

一：pod容器分类
1.1 infrastructure container 基础容器
维护整个pod的网络空间

查看容器的网络

[root@node01 ~]# cat /k8s/cfg/kubelet

KUBELET_OPTS="--logtostderr=true \
--v=4 \
--hostname-override=192.168.247.143 \
--kubeconfig=/k8s/cfg/kubelet.kubeconfig \
--bootstrap-kubeconfig=/k8s/cfg/bootstrap.kubeconfig \
--config=/k8s/cfg/kubelet.config \
--cert-dir=/k8s/ssl \
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"

每次创建pod时，–pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"就会创建基础容器，与pod对应，对于用户是透明的

[root@node01 ~]# docker ps | grep registry	#这个是基础容器
56ad95a6c12c        registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0   "/pause"

2、初始化容器(initcontainers)

Init容器必须在应用程序容器启动之前运行完成，而应用程序容器是并行运行的，所以Init容器能够提供了一种简单的阻塞或延迟应用容器的启动的方法。

Init容器与普通的容器非常像，除了以下两点
1，Init容器总是运行到成功完成为止
2，每个Init容器都必须在下一个Init容器启动之前成功完成

如果 Pod 的Init容器失败，k8s 会不断地重启该Pod，直到 Init 容器成功为止。然而，如果 Pod对应的重启策略（restartPolicy）为Never，它不会重新启动。

3：container 业务容器
并行启动
官方网站：https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

可以有多个运行应用程序的容器，但也可以有一个或多个初始化容器，它们在启动应用程序容器之前就已运行。

初始化容器与常规容器完全一样，除了：

初始化容器始终会运行到完成状态。
每个init容器必须成功完成才能启动下一个容器。
如果Pod的初始化容器失败，Kubernetes将反复重启Pod，直到初始化容器成功。但是，如果Pod具有restartPolicy永不，则Kubernetes不会重新启动Pod。

要为Pod指定初始化容器，将initContainers字段添加到Pod规范中，作为类型为Container的对象数组 和app containers数组一起。初始化容器的状态.status.initContainerStatuses 作为容器状态的数组在字段中返回（类似于该.status.containerStatuses 字段）。

kubelet组件管理
1基础容器和
2初始化容器

运维工作者主要负责业务容器

yaml中的app容器就是业务容器

容器创建有两种：apply和create

apply包含create，即创建新的容器；也可以在原有容器的基础上进行更新

示例：

[root@master daema]# vim myapp.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]

[root@master daema]# kubectl apply -f myapp.yaml 
[root@master daema]# kubectl get pods --all-namespaces -w  #持续监听
[root@master ~]# kubectl get pods -n default 
[root@master ~]# kubectl describe po myapp-pod       #查看描述性信息
[root@master daema]# kubectl get  -f myapp.yaml      #查看yaml文件关联的pod状态
NAME        READY   STATUS     RESTARTS   AGE
myapp-pod   0/1     Init:0/2   0          165m
[root@master daema]# kubectl logs myapp-pod  -c init-myservice    #指定pod中主应用容器的日志
                                                  

镜像拉取策略（image PullPolicy）
IfNotPresent：默认值，镜像在宿主机上不存在时才拉取
Always：每次创建Pod都会重新拉取一次镜像
Never：Pod永远不会主动拉取这个镜像
https://kubernetes.io/docs/concepts/containers/images

示例：

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: private-image-test-1
spec:
  containers:
    - name: uses-private-image
      image: $PRIVATE_IMAGE_NAME
      imagePullPolicy: Always
      command: [ "echo", "SUCCESS" ]
EOF

[root@master daema]# kubectl apply -f myapp.yaml 
pod/myapp-pod unchanged
[root@master daema]#  kubectl get pods
NAME                                READY   STATUS             RESTARTS   AGE
myapp-pod                           0/1     Init:0/2           0          5h15m
mypod                               0/1     CrashLoopBackOff   5          6m41s

//失败的状态的原因是因为命令启动冲突
删除 command: [ “echo”, “SUCCESS” ]

//删除原有的资源

[root@master daema]# kubectl delete -f pod1.yaml 
pod "mypod" deleted

//更新资源

[root@master daema]# kubectl apply -f pod1.yaml 
pod/mypod created
[root@master daema]#  kubectl get pods
NAME                                READY   STATUS     RESTARTS   AGE
myapp-pod                           0/1     Init:0/2   0          5h44m
mypod                               1/1     Running    0          19s

//资源限制
docker中资源限制手段——》Cgroup （）
https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/

Pod和Container的资源请求和限制：

spec.containers[].resources.limits.cpu     //cpu上限 
spec.containers[].resources.limits.memory   //内存上限
spec.containers[].resources.requests.cpu   //创建时分配的基本CPU资源
spec.containers[].resources.requests.memory  //创建时分配的基本内存资源

[root@master daema]# vim test1.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: db
    image: mysql
    env:
    - name: MYSQL_ROOT_PASSWORD
      value: "password"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
  - name: wp
    image: wordpress
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"