技术积累LZ 2020-01-08
在K8s中创建资源的方式有两种:命令行和YAML文件,本次博文主要介绍使用YAML文件的方式,如需使用命令行创建资源请参考K8s资源对象的基本管理
Kubernetes中的YAML文件与配置清单是一样的,根据个人习惯。本次博文统称为YAML文件!
YAML是专门用来配置文件的语言,非常简洁和强大。与了解的properties、XML、json等数据格式,习惯之后就会发现越来越好用。其实YAML就是结合了大部分的标记语言的特性,整合新开发的。
YAML文件的特点:
- 层次分明、结构清晰;
- 使用简单、上手容易;
- 功能强大、语义丰富;
需要特别注意的是:- 大小写敏感;
- 严格要求缩进;
Kubernetes中的YAML文件主要由五个一级字段组成,分别是:
- apiVersion:api版本信息;
- kind:指定创建资源对象的类型;
- metadata:元数据内部的嵌套字段,定义了资源对象的名称、名称空间等;
- spec:规范定义资源应该拥有什么样的特性,依靠控制器确保性能可以满足,满足用户期望的状态。
- status:显示资源的当前状态,K8s就是确保当前状态向目标状态无限靠近从而满足用户期望。代表资源当前的状态;
虽然知道了YAML文件中的一级字段都是什么,但是还是不知道应该怎么写。可以借助以下命令来获取一些帮助信息。
[ ~]# kubectl api-versions //获取当前集群支持的 apiserver版本 [ ~]# kubectl api-resources //获取全部的api资源对象 [ ~]# kubectl explain deployment //查看k8s某个对象的配置清单格式,应该包含哪些字段及使用方法 [ ~]# kubectl explain deployment.spec //这个命令是非常重要的,它可以一级一级来获取帮助
[ ~]# cat web.yaml kind: Deployment //指定要创建的资源对象 apiVersion: extensions/v1beta1 //指定deployment所对应的API版本信息 metadata: name: web //定义deployment的名称 spec: replicas: 2 //指定副本数量 template: metadata: labels: //指定pod的标签 app: web_server spec: containers: - name: nginx //指定pod运行的容器的名称 image: nginx //指定运行容器所需的镜像
[ ~]# kubectl apply -f web.yaml //使用“-f”来指定yaml文件,根据yaml文件中定义的内容生成所需的资源
apply可以指定多次,如果发现文件不同,则更新
[ ~]# kubectl delete -f web.yaml //删除yaml文件中定义的资源
[ ~]# kubectl get deployments. web //查看web控制器所产生的pod NAME READY UP-TO-DATE AVAILABLE AGE web 2/2 2 2 5m50s [ ~]# kubectl describe deployments. web //查看web控制器的详细信息
返回的结果如下:
这样一来,Kubernetes已经根据YAML文件生成了我们所需的pod资源!
[ ~]# kubectl get pod -o wide //查看pod的详细信息 NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES web-d6ff6c799-7jtvd 1/1 Running 0 17m 10.244.2.2 node02 <none> <none> web-d6ff6c799-7tpdc 1/1 Running 0 17m 10.244.1.2 node01 <none> <none>
K8s集群内部测试访问:
[ ~]# cat web-svc.yaml kind: Service apiVersion: v1 metadata: name: web-svc spec: type: NodePort //指定类型为NodePort,可以让外部访问,否则默认情况下是cluster IP,仅限集群内部访问 selector: app: web_server //必须与deployment资源对象的标签进行关联 ports: - protocol: TCP port: 80 //指定要映射到的Cluster IP的端口 targetPort: 80 //指定的是要映射pod中的端口 nodePort: 31000 //指定映射到宿主机的端口,范围是30000~32767 [ ~]# kubectl apply -f web-svc.yaml //生成service的控制文件(yaml中已经定义其名称为web-svc) [ ~]# kubectl get svc web-svc //查看service控制器 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE web-svc NodePort 10.99.32.22 <none> 80:31000/TCP 12m //TYPE:为NodePort,可以使外部访问; //PORT:映射出的端口与我们定义的一样
测试访问:
注意:是访问群集中任意节点都可以访问k8s集群中pod所提供的服务!
[ ~]# kubectl describe svc web-svc //查看service的详细信息
返回的信息如下:
既然说到,Endpoints指定的是后端pod的IP地址,那么下面进行验证:
[ ~]# kubectl get pod -o wide | awk ‘{print $6}‘ //提取后端pod的IP地址 IP 10.244.2.2 10.244.1.2 //与上述查询的结果一样!
我们知道service是有负载均衡的能力,那么是怎么实现的?
其实,背后的原理并没有那么高大上,kube-proxy通过iptables的转发机制来实现负载均衡的效果的,先定义目标IP是service提供的群集IP,然后使用“-j”选项转发到其他iptables规则,接下来验证一下:
[ ~]# kubectl get svc web-svc | awk ‘{print $3}‘ //首先查看service的群集IP地址 CLUSTER-IP 10.99.32.22 [ ~]# iptables-save | grep 10.99.32.22 //查看iptables规则中与群集IP地址相关的内容 -A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.99.32.22/32 -p tcp -m comment --comment "default/web-svc: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ -A KUBE-SERVICES -d 10.99.32.22/32 -p tcp -m comment --comment "default/web-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-3RBUQ3B6P3MTQ3S7 从上述结果中可以看出,当目标地址是群集IP时,就会转发到KUBE-SVC-3RBUQ3B6P3MTQ3S7规则中 [ ~]# iptables-save | grep KUBE-SVC-3RBUQ3B6P3MTQ3S7 :KUBE-SVC-3RBUQ3B6P3MTQ3S7 - [0:0] -A KUBE-NODEPORTS -p tcp -m comment --comment "default/web-svc:" -m tcp --dport 31000 -j KUBE-SVC-3RBUQ3B6P3MTQ3S7 -A KUBE-SERVICES -d 10.99.32.22/32 -p tcp -m comment --comment "default/web-svc: cluster IP" -m tcp --dport 80 -j KUBE-SVC-3RBUQ3B6P3MTQ3S7 -A KUBE-SVC-3RBUQ3B6P3MTQ3S7 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-E3SP5QDRAUFB55IC -A KUBE-SVC-3RBUQ3B6P3MTQ3S7 -j KUBE-SEP-3T3LUFAKMOTS5BKN //从查询结果中可以看出其负载均衡的效果,因为后端只创建了两个pod,所以其概率为0.5
有关K8s的详细介绍还是建议参考K8s中文文档
————————本文到此为止,感谢阅读————————
###host字段指定授权使用该证书的etcd节点IP或子网列表,需要将etcd集群的3个节点都添加其中。cp etcd-v3.3.13-linux-amd64/etcd* /opt/k8s/bin/