资源管理介绍
在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。
kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务
所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。
kubernetes的最小管理单元是pod而不是容器，只能将容器放在Pod中，
kubernetes一般也不会直接管理Pod，而是通过Pod控制器来管理Pod的。
Pod中服务服务的访问是由kubernetes提供的Service资源来实现。
Pod中程序的数据需要持久化是由kubernetes提供的各种存储系统来实现
1.1 资源管理方式
1.1.1 命令式对象管理
显示集群版本
kubectl version显示集群信息
kubectl cluster-info创建一个webcluster控制器，控制器中pod数量为2
kubectl create deployment webcluster --image nginx/nginx:latest --replicas 2查看资源帮助
kubectl explain deployment查看控制器参数帮助
kubectl explain deployment.spec编辑控制器配置
kubectl patch deployments.apps webcluster -p '{"spec": {"replicas":4}}'删除资源
kubectl delete deployments.apps webcluster运行和调试命令示例
运行pod
kubectl run testpod --image nginx/nginx:latest端口暴露
kubectl run testpod --image nginx/nginx:latestkubectl expose pod testpod --port 80 --target-port 80查看资源详细信息
kubectl describe pods testpod查看资源日志
kubectl logs pods/testpod运行交互pod
ctrl+pq退出不停止pod
kubectl run -it testpod --image busybox进入到已经运行的容器，且容器有交互环境
kubectl attach pods/testpod -it在已经运行的pod中运行指定命令
kubectl exec -it pods/testpod1 /bin/bash拷贝文件到pod中
kubectl cp testpod1.yml testpod1:/
kubectl exec -it pods/testpod1 /bin/bash复制pod中的文件到本机
kubectl cp testpod1:/testpod1.yml testpod1.yml运行非交互pod
kubectl run nginx --image nginx/nginx:latest
高级命令示例
利用命令生成yaml模板文件
kubectl create deployment --image nginx/nginx:latest webcluster --dry-run=client -o yaml > webcluster.yml
kubectl apply -f webcluster.yml
使用该文件
[root@k8s-master ~]# kubectl apply -f web.yml查看
[root@k8s-master ~]# kubectl get deployments.apps回收资源
[root@k8s-master ~]# kubectl delete -f web.yml命令修改
[root@k8s-master ~]# kubectl set image deployments/test myapp=myapp:v2[root@k8s-master ~]# kubectl rollout undo deployment test --to-revision 1
什么是pod
- Pod是可以创建和管理Kubernetes计算的最小可部署单元
- 一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。
- 一个pod类似一个豌豆英，包含一个或多个容器(通常是docker)
- 多个容器间共享IPC、Network和UTCnamespace。
2.1创建自主式pod（生产不推荐）
查看所有pods
kubectl get pods建立一个名为timinglee的pod
kubectl run revkarl --image nginx/nginx:latest
显示pod的较为详细的信息
kubectl get pods -o wide
2.2 利用控制器管理pod(推荐)
建立控制器并自动运行pod
kubectl create deployment timinglee --image nginx/nginx:latest2.3应用版本的更新
利用控制器建立pod
kubectl create deployment timinglee --image myapp:v1 --replicas 2暴露端口
kubectl expose deployment timinglee --port 80 --target-port 80
service/timinglee exposed查看历史版本
kubectl rollout history deployment timinglee 更新控制器镜像版本
kubectl set image deployments/timinglee myapp=myapp:v2版本回滚
kubectl rollout undo deployment timinglee --to-revision 12.4利用yaml文件部署应用
获得资源帮助
kubectl explain pod.spec.containers示例：运行简单的单个容器pod
kubectl run timinglee --image myapp:v1 --dry-run=client -o yaml > pod.yml
kubectl apply -f pod.yml运行多个容器pod
vim pod.yml
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1- image: myapp:v2name: web2在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰
vim pod.yml
apiVersion: v1
kind: Pod
metadata:labels:run: timingleename: timinglee
spec:containers:- image: myapp:v1name: web1- image: busybox:latestname: web2command: ["/bin/sh","-c","sleep 1000000"]pod的生命周期
3.1.init容器
- Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
- Init 容器与普通的容器非常像，除了如下两点:
- 它们总是运行到完成
- init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个Init 容器必须运行成功，下一个才能够运行。
- 如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。
3.1.1INIT 容器的功能
- Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
- Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
- 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
- Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
- 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
init容器示例
kubectl run initpod --image myapp:v1 -o yaml > pod.yml
vim pod.yml
apiVersion: v1
kind: Pod
metadata:labels:run: initpodname: initpod
spec:containers:- image: myapp:v1name: myappinitContainers:- name: init-myserviceimage: busyboxcommand: ["sh","-c","until test -e /testfile;do echo wating for myservice;sleep 2;done"] 
探针
3.1 探针实例
3.1.1存活探针示例：
[root@k8s-master ~]# vim timinglee.yml
apiVersion: v1
kind: Pod
metadata:labels:run: livenessname: liveness
spec:containers:- image: reg.zx.org/library/myapp:v1name: myapplivenessProbe:tcpSocket:port: 8080initialDelaySeconds: 3periodSeconds: 1timeoutSeconds: 1[root@k8s-master ~]# kubectl apply -f readiness.yml
pod/liveness created
[root@k8s-master ~]# kubectl get pods3.1.2就绪探针示例：
[root@k8s-master ~]# vim readiness.yml apiVersion: v1
kind: Pod
metadata:labels:run: readnessname: liveness
spec:containers:- image: myapp:v1name: myappreadnessProbe:httpGet:path：/test.htmlport: 80initialDelaySeconds: 1periodSeconds: 3timeoutSeconds: 1[root@k8s-master ~]# kubectl apply -f readiness.yml
pod/readiness created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
init-test 1/1 Running 0 30m
liveness 0/1 CrashLoopBackOff 9 (3m58s ago) 15m
readiness 0/1 Running 0 10s[root@k8s-master ~]# kubectl expose pod readiness --port 80 --target-port 80[root@k8s-master ~]# kubectl describe pods readiness[root@k8s-master ~]# kubectl describe services readiness
Name: readiness
Namespace: default
Labels: run=readiness
Annotations: <none>
Selector: run=readiness
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.101.55.183
IPs: 10.101.55.183
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: #没有暴漏端口，就绪探针探测不满足暴漏条件
Session Affinity: None
Events: <none>[root@k8s-master ~]# kubectl exec pods/readiness -c myapp -- /bin/sh -c "echo test > /usr/share/nginx/html/test.html"[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
init-test 1/1 Running 0 42m
liveness 0/1 CrashLoopBackOff 15 (42s ago) 27m
readiness 1/1 Running 0 3m13s[root@k8s-master ~]# kubectl describe service readiness
Name: readiness
Namespace: default
Labels: run=readiness
Annotations: <none>
Selector: run=readiness
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.101.75.183
IPs: 10.101.75.183
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.1.44:80 #满组条件端口暴漏
Session Affinity: None
Events: <none>
