• container实际上是一个单进程模型 • pod可以类比为进程组概念 • pod在k8s中必须是原子调度单位 • Pod 要解决的问题核心就在于如何让一个 Pod 里的多个容器之间最高效的共享某些资源 和数据。 • 通过infra container的方式共享同一个network namespace • 镜像k8s.gcr.io/pause由汇编语言编写、永远处于“暂停”状态，大小100~200KB • 直接使用localhost通信 • pod内的所有容器共享一份网络资源，一个pod一份。 • 整个pod的生命周期跟infra容器一致，而与其它容器无关 • 所有同属于一个 Pod 的容器，他们共享所有的 volume。
1.查看定义变量
2.列出所有pod
查看demo,显示正在拉取
get pod 显示runing
查看pod是否运行及运行节点
添加外部仓库地址
在master中开启busybox
查看运行中的pod
删除时在delete pod dome 后加 --force可以强制删除
创建Pod应用
拉去实验环境
创建容器，指定镜像
查看运行的节点是否全部就绪，发现在node1和node2上均衡
expose后跟暴露的服务器（deployment）指定暴露容器端口为80，目标端口为80
可以看到svc的名字和刚才创建的demo一样
编辑svc type：NodePor
多了一个80端口分配了32370
资源清单
格式如下： • apiVersion: group/version //指明api资源属于哪个群组和版本，同一个组 可以有多个版本 $ kubectl api-versions //查询命令 • kind: //标记创建的资源类型，k8s主要支持以下资源类别 Pod,ReplicaSet,Deployment,StatefulSet,DaemonSet,Job,Cronjob • metadata: //元数据 name： //对像名称 namespace： //对象属于哪个命名空间 labels： //指定资源标签，标签是一种键值数据 annotations： //用来描述资源的注解 ownerReference:// 用来描述多个资源之间相互关系 • spec: //定义目标资源的期望状态 • status： //用来描述观测到的状态 • $ kubectl explain pod //查询帮助文档
新建pod,并编写pod.yaml文件
-o查看
将打开的yaml导入到pod2.yaml中
可以对文件进行编辑
运行查看结果 
kubectl api-versions
mkdir pod
cd pod/
vim pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod
spec:
containers:
- name: pod1
image: nginx
imagePullPolicy: IfNotPresent
ports:
- name: http
containerPort: 80
hostPort: 80
resources:
limits:
cpu: 0.5
memory: 200Mi
requests:
cpu: 0.5
memory: 200Mi
标签： • $ kubectl get pod --show-labels //查看标签
NAME READY STATUS RESTARTS AGE LABELS demo 2/2 Running 0 8s app=demo
• $ kubectl get pod -l app //过滤包含app的标签
NAME READY STATUS RESTARTS AGE demo 2/2 Running 0 34s
• $ kubectl get pod -L app
NAME READY STATUS RESTARTS AGE APP demo 2/2 Running 0 39s demo
• $ kubectl label pod demo version=v1 //打标签
pod/demo labeled
• $ kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS demo 2/2 Running 0 4m1s app=demo,version=v1
• $ kubectl label pod demo app=nginx --overwrite //更改标签
pod/demo labeled
• $ kubectl get pod --show-labels
NAME READY STATUS RESTARTS AGE LABELS demo 2/2 Running 0 5m40s app=nginx,version=v1
更改标签
编辑文件
查看kube-flannel.yml文件
Pod生命周期
Pod 遵循一个预定义的生命周期，起始于 Pending 阶段，如果至少 其中有一个主要容器正常启动，则进入 Running，之后取决于 Pod 中是否有容器以 失败状态结束而进入 Succeeded 或者 Failed 阶段。
在 Pod 运行期间，kubelet 能够重启容器以处理一些失效场景。 在 Pod 内部，Kubernetes 跟踪不同容器的状态 并确定使 Pod 重新变得健康所需要采取的动作。
在 Kubernetes API 中，Pod 包含规约部分和实际状态部分。 Pod 对象的状态包含了一组 Pod 状况（Conditions）。 如果应用需要的话，你也可以向其中注入自定义的就绪性信息。
Pod 在其生命周期中只会被调度一次。 一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者 被终止。
编辑文件
更改为如下格式
get pod查看
并通过以下方式检查其状态：
kubectl get -f myapp.yaml
kubectl describe -f myapp.yaml
随后创建服务
通过svc可以观察到已打开
使用get pod查看myapp-pod
第二个仍然有问题
继续添加
查看无误
完成 没有出现报错
探针
• 探针 是由 kubelet 对容器执行的定期诊断:
• ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为 诊断成功。
• TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果 端口打开，则诊断被认为是成功的。
• HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功 的。
• 每次探测都将获得以下三种结果之一：
• 成功：容器通过了诊断。
• 失败：容器未通过诊断。
• 未知：诊断失败，因此不会采取任何行动。
• Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：
• livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会 杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针， 则默认状态为 Success。
• readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点 控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初 始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状 态为 Success。
• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测 (startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失 败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提 供启动探测，则默认状态为成功Success。
参数解释：
• initialDelaySeconds pod启动后延迟多久进行检测
• periodSeconds 检测的间隔时间，默认10秒
• timeoutSeconds 检测的超时时间，默认1秒
• successThreshold 检测失败后再次判断成功的阈值，默认1次
• failureThreshold 检测失败的重试次数，默认3次
先确定三台主机都安装nginx
在master主机中写入
启动
get pod 可以看到已经runing
但如果将端口改为8000 
get pod -w 持续查看发现一直在读取
添加就绪探针
readinessProbe:
httpGet: path: /test.html
port: 80 initial
DelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 1
get svc可以看到myservice
再次pod已经成功running
也可以通过svc liveness-http查看到endpoints
