文章目录
- 一、应用部署流程
- 二、服务编排
- 2.1 YAML文件格式说明
- 2.2 部署应用
- 2.2.1 命令部署
- 2.2.2 yaml文件部署
- 2.2.2.1 编写deployment.yaml文件
- 2.2.2.2 编写service.yaml文件
- 2.2.2.3 两个yaml文件混用
- 2.2.2.4 测试——service和deployment的标签不一致导致访问网页混乱
- 2.2.3 自定义yaml文件
- 2.2.3.1 create命令生成
- 2.2.3.2 get命令导出
- 2.2.3.3 查看yaml文件字段
- 三、集群资源利用率
- 3.1 安装插件
- 3.2 命令使用
- 四、查看集群资源
- 五、日志管理
一、应用部署流程
部署流程:
- 编写dockerfile,制作镜像。
- 使用控制器部署pod,部署时需要指定制作的镜像。常见控制器有deployment、statefulset、daemonset。
- 把需要访问交互的应用端口暴露出来,方便数据交互。暴露方式有service、ingress。
- 暴露出来后,客户端就可以正常访问运维了。
基础资源概念:
- Pod:K8s最小部署单元,一组容器的集合。
- Deployment:最常见的控制器,用于更高级别部署和管理Pod。
- Service:为一组Pod提供负载均衡,对外提供统一访问入口。
- Label :标签,附加到某个资源上,用于关联对象、查询和筛选。
- Namespaces :命名空间,将对象逻辑上隔离,也利于权限控制,默认有四个。
- default:默认命名空间。
- kube-system:K8s系统方面的命名空间。
- kube-public:公开的命名空间,谁都可以访问。
- kube-node-lease:K8s内部命名空间。
资源关系图:
二、服务编排
2.1 YAML文件格式说明
- K8s是一个容器编排引擎,使用YAML文件编排要部署应用,因此在学习之前,应先了解YAML语法格式:
- 缩进表示层级关系。
- 不支持制表符“tab”缩进,使用空格缩进。
- 通常开头缩进 2 个空格。
- 字符后缩进 1 个空格,如冒号、逗号等。
- “—” 表示YAML格式,一个文件的开始。
- “#”注释。
2.2 部署应用
2.2.1 命令部署
1.创建一个名为web的deployment,使用镜像nginx。
[root@k8s-master ~]# kubectl create deployment web1 --image=nginx
deployment.apps/web created
2.查看是否创建成功。
3.给名为web1的deployment创建一个service暴露其内部应用,名为text,应用端口为80,svc端口为80,暴露端口为31697。
[root@k8s-master ~]# kubectl expose deploy web1 --name=text --port=80 --target-port=80 --type=NodePort
4.集群任意节点IP:31697,访问web页面。
2.2.2 yaml文件部署
- 命令部署虽然繁杂,但初始学习可以很好的运用参数。等熟练后就可以使用yaml文件部署,操作简单。
- 相关命令:
- 部署:kubectl apply -f xxx.yaml
- 卸载:kubectl delete -f xxx.yaml
2.2.2.1 编写deployment.yaml文件
1.编辑一个yaml文件,K8s官网deployment.yaml文件模板。
[root@k8s-master bck]# cat qingjun1.yaml
apiVersion: apps/v1 ## API版本
kind: Deployment ##资源类型
metadata: ##资源元数据,包括名称、所在命名空间。name: qingjun1 ## 控制器名称。
spec: ## 资源规格,包括副本数量、标签选择器。replicas: 3selector:matchLabels: ##标签选择器,自定义键值对,与metadata.labels保持一致。app: demo2 template: ## Pod模板内容,包括Pod元数据、规格、容器配置。metadata: ##pod元数据。labels:app: demo2spec: ##pod规格,在下面可以定义服务应用。containers: ##容器规格。- name: web ## Pod名称。image: nginx ##镜像地址。
2.导入yaml文件创建deployment。
[root@k8s-master bck]# kubectl apply -f qingjun1.yaml
3.查看创建结果。
2.2.2.2 编写service.yaml文件
1.编辑一个yaml文件,K8s官方service.yaml文件模板。
[root@k8s-master bck]# cat baimu.yaml
apiVersion: v1
kind: Service ##资源类型
metadata: ##资源元数据,包括资源名称、所在命名空间。name: java-demo2 ##资源名称。
spec: ##资源规格,包括标签选择器。selector: ##标签选择器,与需要暴露关联的deployment中的标签保持一致。app: demo2ports:- protocol: TCP ##使用协议。port: 80 ##svc端口,通过clusterip访问使用,默认80。targetPort: 8080 ##容器内运行服务端口type: NodePort ##端口类型,这个类型代表将应用暴露到外面,浏览器能访问。
2.导入yaml文件,查看service。
[root@k8s-master bck]# kubectl apply -f baimu.yaml
[root@k8s-master bck]# kubectl get service
3.访问web页面。
2.2.2.3 两个yaml文件混用
1.创建一个命名空间test。
[root@k8s-master bck]# kubectl create ns test
namespace/test created
2.创建yaml模板文件,我这里创建2个:web1.yaml、web2.yaml。
[root@k8s-master bck]# cat web1.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: web1namespace: test
spec:replicas: 3selector:matchLabels:app: web1template:metadata:labels:app: web1spec:containers:- name: webimage: nginx
---
apiVersion: v1
kind: Service
metadata:name: web1namespace: test
spec:selector:app: web1ports:- protocol: TCPport: 80targetPort: 80type: NodePort[root@k8s-master bck]# cat web2.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: web2namespace: test
spec:replicas: 3selector:matchLabels:app: web2template:metadata:labels:app: web2spec:containers:- name: webimage: httpd
---
apiVersion: v1
kind: Service
metadata:name: web2namespace: test
spec:selector:app: web2ports:- protocol: TCPport: 80targetPort: 80type: NodePort
3.导入两个yaml文件,创建deployment和service。
[root@k8s-master bck]# kubectl apply -f web1.yaml -f web2.yaml
4.查看结果。
[root@k8s-master bck]# kubectl get pod -n test
[root@k8s-master bck]# kubectl get service -n test
5.访问web1是nginx,访问web2是apache。
2.2.2.4 测试——service和deployment的标签不一致导致访问网页混乱
1.现在蒋web2.yaml文件中的service标签改成web1。
2.重新导入web2.yaml文件,访问网页是Nginx的页面。
[root@k8s-master bck]# kubectl apply -f web2.yaml
[root@k8s-master bck]# kubectl get service -n test
3.得出结论,service转发是根据deployment的标签来识别的,这种情况是不应该出现的。
4.此时可以查看service转发pod的IP信息。
[root@k8s-master bck]# kubectl get endpoints -n test
5.所以我们常常会给deploytment定义两个标签,与service标签需要一致。
6.卸载服务。
2.2.3 自定义yaml文件
2.2.3.1 create命令生成
命令示范:
- kubectl create deployment nginx --image=nginx:1.16 -o yaml --dry-run=client > my-deploy.yaml
1.先尝试运行,–dry-run参数是尝试运行不实际创建应用资源对象,选择项有client(客户端)、service(API),–replicas代表创建3个副本。
[root@k8s-master ~]# kubectl create deployment java-demo --image=nginx --replicas=3 --dry-run=client
deployment.apps/java-demo created (dry run)
2.输出yaml文件内容。
[root@k8s-master ~]# kubectl create deployment java-demo --image=nginx --replicas=3 --dry-run=client -o yaml
3.导出yaml文件。
[root@k8s-master ~]# kubectl create deployment java-demo --image=nginx --replicas=3 --dry-run=client -o yaml > deployment.yaml
4.此时可以适当修改导出来的yaml文件内容,因为导出来的内容是给API提交时的内容,有些参数我们用不上。
[root@k8s-master ~]# cat deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:creationTimestamp: null ##时间戳字段,k8s官方维护的,不属于用户定义,删不删出都不影响容器相关操作。这里就可以先删除。labels:app: java-demo ##deployment的标签,用于过滤,与service也要保持一样,四点一线,不常用。name: java-demo
spec:replicas: 3selector:matchLabels:app: java-demostrategy: {} template:metadata:creationTimestamp: nulllabels:app: java-demospec:containers:- image: lizhenliang/java-demoname: java-demoresources: {}
status: {}
2.2.3.2 get命令导出
命令示范:
- kubectl get deployment nginx -o yaml > my-deploy.yaml
- 常常用在将已创建的资源yaml文件导出来,方便调试运维。
1.查看已创建的deployment有哪些。
2.导出deployment的yaml文件。
[root@k8s-master ~]# kubectl get deploy web1 -o yaml > web1.yaml
3.查看导出的yaml文件。这里的内容是从k8s里面导出来的,k8s创建资源时会添加很多字段,所以比create创建出来的yaml文件字段多一些。
4.删除不常用的字段,修改后内容如下。
2.2.3.3 查看yaml文件字段
- 当我们在编写yaml时,若是忘记一些字段是可以通过命令来查看的,这个命令非常常用。
命令示范:
- kubectl explain pods.spec.containers
- kubectl explain deployment
1.查看书写格式。
2.查看第一级别。
3.查看spec第一级别。
4.查看第四级别。
[root@k8s-master bck]# kubectl explain deployment.spec.template.spec.containers
三、集群资源利用率
Metrics Server插件概念:
- 是一个集群范围的资源使用情况的数据聚合器,作为一个应用部署在集群中。
- Metric server从每个节点上Kubelet API收集指标,通过K8s聚合器注册在Master APIServer中。为集群提供Node、Pods资源利用率指标。
- 项目地址
工作原理:
- 使用kubectl top 命令查看资源使用率时,会给apiserver发送请求。
- metric-server是作为pod部署的,此时apiserver向metric-server发送请求查看它收集各个节点上的资源利用率信息。
- metric-server作为聚合器通过https方式与各个节点上的kubelet对接,将各节点上的容器使用信息收集过来。
- kubelet代码里内涵了cadvisor插件,此插件是专门收集容器指标的。
原理图:
官方:
Metrics Server版本 | K8s版本 |
---|---|
0.6.x | 1.19+ |
0.5.x | *1.8+ |
0.4.x | *1.8+ |
0.3.x | 1.8-1.21 |
- 其他版本:
3.1 安装插件
1.根据K8s版本下载对应的yaml文件。
wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/high-availability-1.21+.yaml
2.增加kubelet-insecure-tls参数,这个参数作用是告诉metrics-server不验证kubelet提供的https证书。当然也可以使用携带ca证书来访问,但是要挂载比较麻烦。
3.导入查看,如果状态True并能返回数据说明Metrics Server服务工作正常。
kubectl apply -f metrics-server.yaml kubectl get apiservices |grep metricskubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes
3.2 命令使用
1.查看所有节点cpu使用情况。
2.查看pod的内存使用情况。
四、查看集群资源
1.查看master组件状态。
2.查看节点运行状态。
3.查看资源的详情,此命令在排错时经常用到。
kubectl describe <资源类型> <资源名称>
4.查看资源创建时的yaml文件内容。
kubectl get <资源类型> <资源名称> -o yaml
5.查看资源状态、IP等详情。
kubectl get <资源类型> <资源名称> -o wide
6.查看资源标签。
五、日志管理
工作中需要用到哪些日志?
- 组件日志,比如kubelet、apiserver等等。
- 应用服务日志。
日志类型:
- 标准输出,比如kubelet log 或docker log查看就是将日志输出在屏幕上实时查看。
- 日志文件,直接查看日志文件里记录的日志。
1.查看kubelet组件日志。所有组件除了kubelet是systemd守护进程管理的组件,其他组件都是pod部署。
[root@k8s-node2 ~]# journalctl -u kubelet -f
2.查看其他组件日志。
[root@k8s-node2 ~]# kubectl logs [pod名称] -n [pod所在命名空间]
3.系统日志,有的组件可以和系统进行交互,有些信息也可以在系统日志中查看。
4.查看标准输出到宿主机的日志文件。
日志管理流程:
- 使用kubectl logs查看日志时,会给apiserver发送请求,apiserver再给对应节点上的kubelet发送请求日志。
- 目标节点上的kubelet给docker发送请求,尝试调取docker管理的日志文件。
- 最后将docker管理的日志我呢见内容标准输到屏幕。
/var/lib/docker/containers/<container-id>/<container-id>-json.log
5.查看容器内日志文件。