Kubernetes 基础架构实践 二
目录
Pod控制器
Workload (工作负载)
控制器又称工作负载是用于实现管理pod的中间层，确保pod资源符合预期的状态，pod的资源出现故障时，会尝试 进行重启，当根据重启策略无效，则会重新新建pod的资源。
- ReplicaSet: 代用户创建指定数量的pod副本数量，确保pod副本数量符合预期状态，并且支持滚动式自动扩容和缩容功能
- Deployment：工作在ReplicaSet之上，用于管理无状态应用，目前来说最好的控制器。支持滚动更新和回滚功能，提供声明式配置
- DaemonSet：用于确保集群中的每一个节点只运行特定的pod副本，通常用于实现系统级后台任务。比如EFK服务
- Job：只要完成就立即退出，不需要重启或重建
- Cronjob：周期性任务控制，不需要持续后台运行
- StatefulSet：管理有状态应用
Deployment
myblog/deployment/deploy-mysql.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: mysql
namespace: jds
spec:
replicas: 1 #指定Pod副本数
selector: #指定Pod的选择器
matchLabels:
app: mysql
template:
metadata:
labels: #给Pod打label
app: mysql
spec:
volumes:
- name: mysql-data
hostPath:
path: /opt/mysql/data
nodeSelector: # 使用节点选择器将Pod调度到指定label的节点
component: mysql
hostNetwork: true
containers:
- name: mysql
image: 10.2.2.10:5000/mysql:5.7-utf8
ports:
- containerPort: 3306
env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_USER
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_PASSWD
- name: MYSQL_DATABASE
value: "myblog"
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
readinessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
tcpSocket:
port: 3306
initialDelaySeconds: 15
periodSeconds: 20
volumeMounts:
- name: mysql-data
mountPath: /var/lib/mysql
myblog/deployment/deploy-myblog.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: myblog
namespace: jds
spec:
replicas: 1 #指定Pod副本数
selector: #指定Pod的选择器
matchLabels:
app: myblog
template:
metadata:
labels: #给Pod打label
app: myblog
spec:
containers:
- name: myblog
image: 10.2.2.10:5000/myblog:v1
imagePullPolicy: IfNotPresent
env:
- name: MYSQL_HOST
valueFrom:
configMapKeyRef:
name: myblog
key: MYSQL_HOST
- name: MYSQL_PORT
valueFrom:
configMapKeyRef:
name: myblog
key: MYSQL_PORT
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_USER
- name: MYSQL_PASSWD
valueFrom:
secretKeyRef:
name: myblog
key: MYSQL_PASSWD
ports:
- containerPort: 8002
resources:
requests:
memory: 100Mi
cpu: 50m
limits:
memory: 500Mi
cpu: 100m
livenessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒
periodSeconds: 15 # 执行探测的频率
timeoutSeconds: 2 # 探测超时时间
readinessProbe:
httpGet:
path: /blog/index/
port: 8002
scheme: HTTP
initialDelaySeconds: 10
timeoutSeconds: 2
periodSeconds: 15
创建Deployment
## 删除之前创建的
$ kubectl delete -n jds pod mysql
pod "mysql" deleted
$ kubectl delete -n jds pod myblog
pod "myblog" deleted
## 创建Deployment
$ kubectl create -f deploy-mysql.yaml
deployment.apps/mysql created
$ kubectl create -f deploy-myblog.yaml
deployment.apps/myblog created
查看Deployment
# kubectl api-resources
$ kubectl -n jds get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
myblog 1/1 1 1 2m20s
mysql 1/1 1 1 2m24s
* `NAME` 列出了集群中 Deployments 的名称。
* `READY`显示当前正在运行的副本数/期望的副本数。
* `UP-TO-DATE`显示已更新以实现期望状态的副本数。
* `AVAILABLE`显示应用程序可供用户使用的副本数。
* `AGE` 显示应用程序运行的时间量。
# 查看pod
$ kubectl -n jds get pods
NAME READY STATUS RESTARTS AGE
myblog-55f54b6c6b-htljx 1/1 Running 0 3m10s
mysql-6cd46b56b6-9dp8t 1/1 Running 0 3m14s
# 查看replicaSet
$ kubectl -n jds get rs
NAME DESIRED CURRENT READY AGE
myblog-55f54b6c6b 1 1 1 4m1s
mysql-6cd46b56b6 1 1 1 4m5s
$ kubectl -n jds get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myblog-55f54b6c6b-htljx 1/1 Running 0 7m56s 10.244.2.20 k8s-slave2 <none> <none>
mysql-6cd46b56b6-9dp8t 1/1 Running 0 8m 10.2.2.11 k8s-slave1 <none> <none>
副本保障机制
controller实时检测pod状态，并保障副本数一直处于期望的值
## 删除pod，观察pod状态变化
$ kubectl -n jds delete pod myblog-7c96c9f76b-qbbg7
pod "myblog-55f54b6c6b-htljx" deleted
## 观察pod, 又自动启动了一个pod
$ kubectl get pods -o wide
kubectl -n jds get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myblog-55f54b6c6b-fbnf9 1/1 Running 0 82s 10.244.1.19 k8s-slave1 <none> <none>
mysql-6cd46b56b6-9dp8t 1/1 Running 0 11m 10.2.2.11 k8s-slave1 <none> <none>
## 设置两个副本, 或者通过kubectl -n jds edit deploy myblog的方式，最好通过修改文件，然后apply的方式，这样yaml文件可以保持同步
$ kubectl -n jds scale deploy myblog --replicas=2
deployment.apps/myblog scaled
# 观察pod, 自动又成了1个 myblog pods
$ kubectl -n jds get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
myblog-55f54b6c6b-fbnf9 1/1 Running 0 4m18s 10.244.1.19 k8s-slave1 <none> <none>
myblog-55f54b6c6b-j78zx 1/1 Running 0 25s 10.244.2.21 k8s-slave2 <none> <none>
mysql-6cd46b56b6-9dp8t 1/1 Running 0 14m 10.2.2.11 k8s-slave1 <none> <none>
Pod驱逐策略
K8S 有个特色功能叫 pod eviction，它在某些场景下如节点 NotReady，或者资源不足时，把 pod 驱逐至其它节点，这也是出于业务保护的角度去考虑的
-
Kube-controller-manager: 周期性检查所有节点状态，当节点处于 NotReady 状态超过一段时间后，驱逐该节点上所有 pod，停掉kubelet
pod-eviction-timeout：NotReady 状态节点超过该时间后，执行驱逐，默认 5 min
## 将 pod-eviction-timeout 定义到下面配置文件里 ## vim /etc/kubernetes/manifests/kube-controller-manager.yaml spec: containers: - command: - kube-controller-manager - --allocate-node-cidrs=true - --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf - --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf - --bind-address=127.0.0.1 - --pod-eviction-timeout=300s ... -
Kubelet: 周期性检查本节点资源，当资源不足时，按照优先级驱逐部分 pod
memory.available：节点可用内存nodefs.available：节点根盘可用存储空间nodefs.inodesFree：节点inodes可用数量imagefs.available：镜像存储盘的可用空间imagefs.inodesFree：镜像存储盘的inodes可用数量
服务更新
修改服务，重新打tag模拟服务更新
更新方式：
- 修改yaml文件，使用
kubectl -n jds apply -f deploy-myblog.yaml来应用更新 kubectl -n jds edit deploy myblog在线更新kubectl -n jds set image deploy myblog myblog=10.2.2.10:5000/myblog:v2 --record
修改文件测试：
## 添加版本v2测试
$ vi /opt/python-demo/blog/templates/index.html
$ docker build . -t 10.2.2.10:5000/myblog:v2 -f Dockerfile
$ docker push 10.2.2.10:5000/myblog:v2
更新策略
...
spec:
replicas: 2 #指定Pod副本数
selector: #指定Pod的选择器
matchLabels:
app: myblog
strategy:
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
type: RollingUpdate #指定更新方式为滚动更新，默认策略，通过get deploy yaml查看
...
策略控制：
- maxSurge：最大激增数, 指更新过程中, 最多可以比replicas预先设定值多出的pod数量, 可以为固定值或百分比,默认为desired Pods数的25%。计算时向上取整(比如3.4，取4)，更新过程中最多会有replicas + maxSurge个pod
- maxUnavailable： 指更新过程中, 最多有几个pod处于无法服务状态 , 可以为固定值或百分比，默认为desired Pods数的25%。计算时向下取整(比如3.6，取3)
在Deployment rollout时，需要保证Available(Ready) Pods数不低于 desired pods number - maxUnavailable; 保证所有的非异常状态Pods数不多于 desired pods number + maxSurge
以myblog为例，使用默认的策略，更新过程:
- maxSurge 25%，2个实例，向上取整，则maxSurge为1，意味着最多可以有2+1=3个Pod，那么此时会新创建1个ReplicaSet，RS-new，把副本数置为1，此时呢，副本控制器就去创建这个新的Pod
- 同时，maxUnavailable是25%，副本数2*25%，向下取整，则为0，意味着，滚动更新的过程中，不能有少于2个可用的Pod，因此，旧的Replica（RS-old）会先保持不动，等RS-new管理的Pod状态Ready后，此时已经有3个Ready状态的Pod了，那么由于只要保证有2个可用的Pod即可，因此，RS-old的副本数会有2个变成1个，此时，会删掉一个旧的Pod
- 删掉旧的Pod的时候，由于总的Pod数量又变成2个了，因此，距离最大的3个还有1个Pod可以创建，所以，RS-new把管理的副本数由1改成2，此时又会创建1个新的Pod，等RS-new管理了2个Pod都ready后，那么就可以把RS-old的副本数由1置为0了，这样就完成了滚动更新
#查看滚动更新事件
$ kubectl -n jds describe deploy myblog
...
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal ScalingReplicaSet 11s deployment-controller Scaled up replica set myblog-6cf56fc848 to 1
Normal ScalingReplicaSet 11s deployment-controller Scaled down replica set myblog-6fdcf98f9 to 1
Normal ScalingReplicaSet 11s deployment-controller Scaled up replica set myblog-6cf56fc848 to 2
Normal ScalingReplicaSet 6s deployment-controller Scaled down replica set myblog-6fdcf98f9 to 0
$ kubectl get rs
NAME DESIRED CURRENT READY AGE
myblog-6cf56fc848 2 2 2 16h
myblog-6fdcf98f9 0 0 0 16h
服务回滚
通过滚动升级的策略可以平滑的升级Deployment，若升级出现问题，需要最快且最好的方式回退到上一次能够提供正常工作的版本。为此K8S提供了回滚机制
revision：更新应用时，K8S都会记录当前的版本号，即为revision，当升级出现问题时，可通过回滚到某个特定的revision，默认配置下，K8S只会保留最近的几个revision，可以通过Deployment配置文件中的spec.revisionHistoryLimit属性增加revision数量，默认是10。
查看当前版本：
$ kubectl -n jds rollout history deploy myblog ##CHANGE-CAUSE为空
deployment.apps/myblog
REVISION CHANGE-CAUSE
1 <none>
$ kubectl delete -f deploy-myblog.yaml ## 方便演示到具体效果，删掉已有deployment
deployment.apps "myblog" deleted
记录回滚版本：
## 将副本数修改为2 replicas: 2
$ kubectl create -f deploy-myblog.yaml --record
deployment.apps/myblog created
$ kubectl -n jds set image deploy myblog myblog=10.2.2.10:5000/myblog:v2 --record=true
查看deployment更新历史：
$ kubectl -n jds rollout history deploy myblog
deployment.apps/myblog
REVISION CHANGE-CAUSE
1 kubectl create --filename=deploy-myblog.yaml --record=true
2 kubectl set image deploy myblog myblog=10.2.2.10:5000/myblog:v2 --namespace=jds --record=true
回滚到具体的REVISION:
## --to-revision=1, 选择REVISION 回滚记录的序号
$ kubectl -n jds rollout undo deploy myblog --to-revision=1
deployment.extensions/myblog rolled back
# 访问应用测试
Kubernetes服务访问之Service
通过上面，能够通过Deployment来创建一组Pod来提供具有高可用性的服务。虽然每个Pod都会分配一个单独的Pod IP，然而却存在如下两个问题：
- Pod IP仅仅是集群内可见的虚拟IP，外部无法访问
- Pod IP会随着Pod的销毁而消失，当ReplicaSet对Pod进行动态伸缩时，Pod IP可能随时随地都会变化，这样对于访问这个服务带来了难度
Service 负载均衡之Cluster IP
service是一组pod的服务抽象，相当于一组pod的LB，负责将请求分发给对应的pod。service会为这个LB提供一个IP，一般称为cluster IP 。使用Service对象，通过selector进行标签选择，找到对应的Pod
myblog/deployment/svc-myblog.yaml
apiVersion: v1
kind: Service
metadata:
name: myblog
namespace: jds
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8002
selector:
app: myblog
type: ClusterIP
操作演示：
## 别名
$ alias kn='kubectl -n jds'
## 创建服务
$ kn create -f svc-myblog.yaml
service/myblog created
## 查看pod 和 node 的标签
$ kubectl get nodes --show-labels
$ kn get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myblog-55f54b6c6b-2fhgt 1/1 Running 0 13h app=myblog,pod-template-hash=55f54b6c6b
mysql-6cd46b56b6-9dp8t 1/1 Running 0 15h app=mysql,pod-template-hash=6cd46b56b6
## service = svc
$ kn get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.96.136.128 <none> 80/TCP 12m
$ kn describe svc myblog
Name: myblog
Namespace: jds
Labels: <none>
Annotations: <none>
Selector: app=myblog
Type: ClusterIP
IP: 10.96.136.128
Port: <unset> 80/TCP
TargetPort: 8002/TCP
Endpoints: 10.244.1.23:8002
Session Affinity: None
Events: <none>
# 注意 若一开始是2个副本集 可以删除一个pod 在看cluster IP是否会浮动
# 强制删除pod
$ kubectl delete -n jds pod myblog-55f54b6c6b-2fhgt --force --grace-period=0
warning: Immediate deletion does not wait for confirmation that the running resource has been terminated. The resource may continue to run on the cluster indefinitely.
pod "myblog-55f54b6c6b-2fhgt" force deleted
## 扩容myblog服务
$ kn scale deploy myblog --replicas=2
deployment.extensions/myblog scaled
## 再次查看
$ kn describe svc myblog
Name: myblog
Namespace: jds
Labels: <none>
Annotations: <none>
Selector: app=myblog
Type: ClusterIP
IP: 10.96.136.128
Port: <unset> 80/TCP
TargetPort: 8002/TCP
Endpoints: 10.244.1.23:8002,10.244.2.24:8002
Session Affinity: None
Events: <none>
$ kn get po --show-labels
NAME READY STATUS RESTARTS AGE LABELS
myblog-55f54b6c6b-2fhgt 1/1 Running 0 13h app=myblog,pod-template-hash=55f54b6c6b
myblog-55f54b6c6b-lr4cl 1/1 Running 0 13h app=myblog,pod-template-hash=55f54b6c6b
mysql-6cd46b56b6-9dp8t 1/1 Running 0 15h app=mysql,pod-template-hash=6cd46b56b6
Service与Pod如何关联:
service对象创建的同时，会创建同名的endpoints对象，若服务设置了readinessProbe, 当readinessProbe检测失败时，endpoints列表中会剔除掉对应的pod_ip，这样流量就不会分发到健康检测失败的Pod中
kn get endpoints myblog
NAME ENDPOINTS AGE
myblog 10.244.1.24:8002,10.244.2.24:8002 29m
Service Cluster-IP如何访问:
$ kn get svc myblog
$ curl 10.96.136.128/blog/index/
为mysql服务创建service：
myblog/deployment/svc-mysql.yaml
apiVersion: v1
kind: Service
metadata:
name: mysql
namespace: jds
spec:
ports:
- port: 3306
protocol: TCP
targetPort: 3306
selector:
app: mysql
type: ClusterIP
访问mysql：
$ kn create -f svc-mysql.yaml
service/mysql created
$ kn get svc mysql
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mysql ClusterIP 10.109.128.174 <none> 3306/TCP 42s
$ curl 10.109.128.174:3306
目前使用hostNetwork部署，通过宿主机ip+port访问，弊端：
- 服务使用hostNetwork，使得宿主机的端口大量暴漏，存在安全隐患
- 容易引发端口冲突
服务均属于k8s集群，尽可能使用k8s的网络访问，因此可以对目前myblog访问mysql的方式做改造：
- 为mysql创建一个固定clusterIp的Service，把clusterIp配置在myblog的环境变量中
- 利用集群服务发现的能力，组件之间通过service name来访问
服务发现
在k8s集群中，组件之间可以通过定义的Service名称实现通信
演示服务发现：
## 演示思路：在myblog的容器中直接通过service名称访问服务，观察是否可以访问通
## 先查看服务
$ kn get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.96.136.128 <none> 80/TCP 44m
mysql ClusterIP 10.109.128.174 <none> 3306/TCP 8m39s
$ kn get pods
NAME READY STATUS RESTARTS AGE
myblog-55f54b6c6b-lr4cl 1/1 Running 0 14h
myblog-55f54b6c6b-v8jz6 1/1 Running 0 21m
mysql-6cd46b56b6-9dp8t 1/1 Running 0 16h
## 进入myblog容器
$ kubectl -n jds exec -ti myblog-55f54b6c6b-lr4cl bash
[root@myblog-55f54b6c6b-lr4cl myblog]# curl mysql:3306
[root@myblog-55f54b6c6b-lr4cl myblog]# curl myblog/blog/index/
虽然podip和clusterip都不固定，但是service name是固定的，而且具有完全的跨集群可移植性，因此组件之间调用的同时，完全可以通过service name去通信，这样避免了大量的ip维护成本，使得服务的yaml模板更加简单。因此可以对mysql和myblog的部署进行优化改造：
- mysql可以去掉hostNetwork部署，使得服务只暴漏在k8s集群内部网络
- configMap中数据库地址可以换成Service名称，这样跨环境的时候，配置内容基本上可以保持不用变化
修改deploy-mysql.yaml
$ vim deploy-mysql.yaml
...
spec:
hostNetwork: true # 去掉此行
volumes:
- name: mysql-data
hostPath:
path: /opt/mysql/data
...
修改configmap.yaml
$ kn edit cm myblog
configmap/myblog edited
apiVersion: v1
kind: ConfigMap
metadata:
name: myblog
namespace: jds
data:
MYSQL_HOST: "mysql" # 此处替换为mysql
MYSQL_PORT: "3306"
应用修改：
$ kubectl delete -f deployment-mysql.yaml
$ kubectl create -f deployment-mysql.yaml
## myblog不用动，会自动因健康检测不过而重启
MYSQL_HOST= , 由原来的IP换成了变量
服务发现实现：
CoreDNS是一个Go语言实现的链式插件DNS服务端，是CNCF成员，是一个高性能、易扩展的DNS服务端
$ kubectl -n kube-system get pods -o wide | grep dns
coredns-58cc8c89f4-fm5k2 1/1 Running 5 9d 10.244.0.12 k8s-master <none> <none>
coredns-58cc8c89f4-r5tft 1/1 Running 5 9d 10.244.0.13 k8s-master <none> <none>
# 查看myblog的pod解析配置
$ kubectl -n jds exec -ti myblog-55f54b6c6b-lr4cl bash
[root@myblog-55f54b6c6b-lr4cl myblog]# cat /etc/resolv.conf
nameserver 10.96.0.10
search jds.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
[root@myblog-55f54b6c6b-lr4cl myblog]# curl mysql.jds.svc.cluster.local:3306
## 10.96.0.10 从哪来
$ kubectl -n kube-system get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kube-dns ClusterIP 10.96.0.10 <none> 53/UDP,53/TCP,9153/TCP 9d
## 启动pod的时候，会把kube-dns服务的cluster-ip地址注入到pod的resolve解析配置中，同时添加对应的namespace的search域。 因此跨namespace通过service name访问的话，需要添加对应的namespace名称，
service_name.namespace
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 9d
Service负载均衡之NodePort
cluster-ip为虚拟地址，只能在k8s集群内部进行访问，集群外部如果访问内部服务，实现方式之一为使用NodePort方式。NodePort会默认在 30000-32767 ，不指定的会随机使用其中一个
myblog/deployment/svc-myblog-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
name: myblog-np
namespace: jds
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8002
selector:
app: myblog
type: NodePort
查看并访问服务：
$ kn create -f svc-myblog-nodeport.yaml
service/myblog-np created
$ kn get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
myblog ClusterIP 10.96.136.128 <none> 80/TCP 94m
myblog-np NodePort 10.101.5.11 <none> 80:30921/TCP 16s
mysql ClusterIP 10.109.128.174 <none> 3306/TCP 59m
## 集群内每个节点的NodePort端口都会进行监听
$ curl 10.2.2.10:30921/blog/index/
我的博客列表
$ curl 10.2.2.11:30921/blog/index/
我的博客列表
## 浏览器访问
思考：
- NodePort的端口监听如何转发到对应的Pod服务？
- CLUSTER-IP为虚拟IP，集群内如何通过虚拟IP访问到具体的Pod服务？
kube-proxy
运行在每个节点上，监听 API Server 中服务对象的变化，再通过创建流量路由规则来实现网络的转发。参照
有三种模式：
-
User space, 让 Kube-Proxy 在用户空间监听一个端口，所有的 Service 都转发到这个端口，然后 Kube-Proxy 在内部应用层对其进行转发 ， 所有报文都走一遍用户态，性能不高，k8s v1.2版本后废弃
-
Iptables， 当前默认模式，完全由 IPtables 来实现， 通过各个node节点上的iptables规则来实现service的负载均衡，但是随着service数量的增大，iptables模式由于线性查找匹配、全量更新等特点，其性能会显著下降
-
IPVS， 与iptables同样基于Netfilter，但是采用的hash表，因此当service数量达到一定规模时，hash查表的速度优势就会显现出来，从而提高service的服务性能。 k8s 1.8版本开始引入，1.11版本开始稳定，需要开启宿主机的ipvs模块
IPtables模式示意图：
$ iptables-save | grep -v myblog-np | grep "jds/myblog"
-A KUBE-SERVICES ! -s 10.244.0.0/16 -d 10.96.136.128/32 -p tcp -m comment --comment "jds/myblog: cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SERVICES -d 10.96.136.128/32 -p tcp -m comment --comment "jds/myblog: cluster IP" -m tcp --dport 80 -j KUBE-SVC-HNPXLKIY6BVOTTG2
$ iptables-save | grep KUBE-SVC-HNPXLKIY6BVOTTG2
:KUBE-SVC-HNPXLKIY6BVOTTG2 - [0:0]
-A KUBE-SERVICES -d 10.96.136.128/32 -p tcp -m comment --comment "jds/myblog: cluster IP" -m tcp --dport 80 -j KUBE-SVC-HNPXLKIY6BVOTTG2
-A KUBE-SVC-HNPXLKIY6BVOTTG2 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BZEPM6POXQ5UAW4H
-A KUBE-SVC-HNPXLKIY6BVOTTG2 -j KUBE-SEP-QW7BLDR25O3SIRT4
$ iptables-save | grep KUBE-SEP-BZEPM6POXQ5UAW4H
:KUBE-SEP-BZEPM6POXQ5UAW4H - [0:0]
-A KUBE-SEP-BZEPM6POXQ5UAW4H -s 10.244.1.24/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-BZEPM6POXQ5UAW4H -p tcp -m tcp -j DNAT --to-destination 10.244.1.24:8002
-A KUBE-SVC-HNPXLKIY6BVOTTG2 -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-BZEPM6POXQ5UAW4H
$ iptables-save | grep KUBE-SEP-QW7BLDR25O3SIRT4
:KUBE-SEP-QW7BLDR25O3SIRT4 - [0:0]
-A KUBE-SEP-QW7BLDR25O3SIRT4 -s 10.244.2.24/32 -j KUBE-MARK-MASQ
-A KUBE-SEP-QW7BLDR25O3SIRT4 -p tcp -m tcp -j DNAT --to-destination 10.244.2.24:8002
-A KUBE-SVC-HNPXLKIY6BVOTTG2 -j KUBE-SEP-QW7BLDR25O3SIRT4
Kubernetes服务访问之Ingress
对于Kubernetes的Service，无论是Cluster-Ip和NodePort均是四层的负载，集群内的服务如何实现七层的负载均衡，这就需要借助于Ingress，Ingress控制器的实现方式有很多，比如nginx, Contour, Haproxy, trafik, Istio。几种常用的ingress功能对比和选型可以参考这里
Ingress-nginx是7层的负载均衡器 ，负责统一管理外部对k8s cluster中Service的请求。主要包含：
-
ingress-nginx-controller：根据用户编写的ingress规则（创建的ingress的yaml文件），动态的去更改nginx服务的配置文件，并且reload重载使其生效（是自动化的，通过lua脚本来实现）；
-
Ingress资源对象：将Nginx的配置抽象成一个Ingress对象
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: simple-example
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /
backend:
serviceName: service1
servicePort: 8080
示意图：
实现逻辑
- ingress controller通过和kubernetes api交互，动态的去感知集群中ingress规则变化
- 然后读取ingress规则(规则就是写明了哪个域名对应哪个service)，按照自定义的规则，生成一段nginx配置
- 再写到nginx-ingress-controller的pod里，这个Ingress controller的pod里运行着一个Nginx服务，控制器把生成的nginx配置写入/etc/nginx/nginx.conf文件中
- 然后reload一下使配置生效。以此达到域名分别配置和动态更新的问题
安装
$ wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.30.0/deploy/static/mandatory.yaml
## 或者使用myblog/deployment/ingress/mandatory.yaml
## 修改部署节点
$ grep -n5 nodeSelector mandatory.yaml
212- spec:
213- hostNetwork: true #添加为host模式
214- # wait up to five minutes for the drain of connections
215- terminationGracePeriodSeconds: 300
216- serviceAccountName: nginx-ingress-serviceaccount
217: nodeSelector:
218- ingress: "true" #替换此处，来决定将ingress部署在哪些机器
219- containers:
220- - name: nginx-ingress-controller
221- image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.30.0
222- args:
创建ingress
# 为k8s-master节点添加label
$ kubectl label node k8s-master ingress=true
$ kubectl create -f mandatory.yaml
namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.apps/nginx-ingress-controller created
limitrange/ingress-nginx created
$ kubectl get ns | grep nginx
ingress-nginx Active 3d
$ kubectl -n ingress-nginx get pod
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-b54b857c-qb2mx 1/1 Running 3 3d
## 查看标签 label 命令
[root@k8s-master opt]# kubectl get node --show-labels
NAME STATUS ROLES AGE VERSION LABELS
k8s-master Ready master 5d23h v1.16.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,ingress=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-master,kubernetes.io/os=linux,node-role.kubernetes.io/master=
k8s-slave1 Ready <none> 5d23h v1.16.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,component=mysql,ingress=true,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-slave1,kubernetes.io/os=linux
k8s-slave2 Ready <none> 5d23h v1.16.2 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8s-slave2,kubernetes.io/os=linux
#注意：如果一开始搭建k8s环境时没有指定master节点为node节点 且无上一步 # 为k8s-master节点添加label时，是无法被调度到slave1上的，即master上有污点
[root@k8s-master opt]# kubectl -n ingress-nginx get pod
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-766b7d9f4-d59ds 0/1 Pending 0 35s
[root@k8s-master opt]# kubectl label node k8s-slave1 ingress=true
node/k8s-slave1 labeled
[root@k8s-master opt]# kubectl -n ingress-nginx get pod
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-766b7d9f4-d59ds 0/1 ContainerCreating 0 2m22s
[root@k8s-master opt]# kubectl -n ingress-nginx get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-ingress-controller 1/1 1 1 65s
使用示例：myblog/deployment/ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myblog
namespace: jds
spec:
rules:
- host: myblog.jds.com
http:
paths:
- path: /
backend:
serviceName: myblog
servicePort: 80
启动示例
$ kubectl create -f ingress.yaml
ingress.extensions/myblog created
## ingress = ing
$ kubectl -n jds get ingress
NAME HOSTS ADDRESS PORTS AGE
myblog myblog.jds.com 80 36m
$ kubectl -n jds get ing
NAME HOSTS ADDRESS PORTS AGE
myblog myblog.jds.com 80 32s
$ kubectl -n jds describe ingress myblog
Name: myblog
Namespace: jds
Address:
Default backend: default-http-backend:80 (<none>)
Rules:
Host Path Backends
---- ---- --------
myblog.jds.com
/ myblog:80 (10.244.1.24:8002,10.244.2.24:8002)
Annotations:
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal CREATE 113s nginx-ingress-controller Ingress jds/myblog
ingress-nginx动态生成upstream配置：
$ kubectl -n ingress-nginx get pods
NAME READY STATUS RESTARTS AGE
nginx-ingress-controller-766b7d9f4-tzv5t 1/1 Running 0 3h51m
$ kubectl -n ingress-nginx exec -ti nginx-ingress-controller-766b7d9f4-tzv5t bash
bash-5.0$ ps aux
bash-5.0$ grep -n "myblog" /etc/nginx/nginx.conf
...
server_name myblog.jds.com ;
listen 80 ;
listen [::]:80 ;
listen 443 ssl http2 ;
listen [::]:443 ssl http2 ;
set $proxy_upstream_name "-";
ssl_certificate_by_lua_block {
certificate.call()
}
location / {
set $namespace "jds";
set $ingress_name "myblog";
...
访问
域名解析服务，将 myblog.jds.com解析到ingress的地址上。ingress是支持多副本的，高可用的情况下，生产的配置是使用lb服务（内网F5设备，公网elb、slb、clb，解析到各ingress的机器，如何域名指向lb地址）
本机添加如下hosts记录
#先查看ip在哪个pod上
$ kubectl -n ingress-nginx get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-ingress-controller-766b7d9f4-tzv5t 1/1 Running 0 5h2m 10.2.2.11 k8s-slave1 <none> <none>
10.2.2.10 myblog.jds.com
然后，访问 http://myblog.luffy.com/blog/index/
HTTPS访问：
## 自签名证书
$ mkdir cert && cd cert
$ openssl req -x509 -nodes -days 2920 -newkey rsa:2048 -keyout tls.key -out tls.crt -subj "/CN=*.luffy.com/O=ingress-nginx"
Generating a 2048 bit RSA private key
.........................+++
.......................................................................+++
writing new private key to 'tls.key'
-----
## 证书信息保存到secret对象中，ingress-nginx会读取secret对象解析出证书加载到nginx配置中
$ kubectl -n jds create secret tls https-secret --key tls.key --cert tls.crt
secret/https-secret created
修改vim ingress-tls.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: myblog-tls
namespace: jds
spec:
rules:
- host: myblog.jds.com
http:
paths:
- path: /
backend:
serviceName: myblog
servicePort: 80
tls:
- hosts:
- myblog.jds.com
secretName: https-secret
查看创建的信息
$ kubectl create -f ingress-tls.yaml
ingress.extensions/myblog-tls created
$ kubectl -n jds get ing
NAME HOSTS ADDRESS PORTS AGE
myblog myblog.jds.com 80 37m
myblog-tls myblog.jds.com 80, 443 8s
然后，访问 https://myblog.jds.com/blog/index/
多路径转发及重写的实现
- 多path转发示例：
目标
myblog.jds.com -> 10.2.2.10 -> /foo service1:4200
/bar service2:8080
/ myblog:80
实现:
## vim ingress-path.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: simple-fanout-example
namespace: jds
spec:
rules:
- host: myblog.jds.com
http:
paths:
- path: /foo
backend:
serviceName: service1
servicePort: 4200
- path: /bar
backend:
serviceName: service2
servicePort: 8080
- path: /
backend:
serviceName: myblog
servicePort: 80
- nginx的URL重写:
目标
myblog.jds.com -> 10.2.2.10 -> /foo/ myblog:80/admin/
实现：
## vim ingress-path2.yaml
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: rewrite-path
namespace: jds
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /admin/$1
spec:
rules:
- host: myblog.jds.com
http:
paths:
- path: /foo/(.*)
backend:
serviceName: myblog
servicePort: 80
访问测试
小结
- 核心描述如何通过k8s管理业务应用
- 介绍k8s的架构、核心组件和工作流程，使用kubeadm快速安装k8s集群
- 定义Pod.yaml，将myblog和mysql打包在同一个Pod中，myblog使用localhost访问mysql
- mysql数据持久化，为myblog业务应用添加了健康检查和资源限制
- 将myblog与mysql拆分，使用独立的Pod管理
- yaml文件中的环境变量存在账号密码明文等敏感信息，使用configMap和Secret来统一配置，优化部署
- 只用Pod去直接管理业务应用，对于多副本的需求，很难实现，因此使用Deployment Workload
- 有了多副本，多个Pod如何去实现LB入口，因此引入了Service的资源类型，有CLusterIp和NodePort
- ClusterIP是四层的IP地址，不固定，不具备跨环境迁移，因此利用coredns实现集群内服务发现，组件之间直接通过Service名称通信，实现配置的去IP化
- 对Django应用做改造，django直接使用mysql:3306实现数据库访问
- 为了实现在集群外部对集群内服务的访问，因此创建NodePort类型的Service
- 介绍了Service的实现原理，通过kube-proxy利用iptables或者ipvs维护服务访问规则，实现虚拟IP转发到具体Pod的需求
- 为了实现集群外使用域名访问myblog，因此引入Ingress资源，通过定义访问规则，实现七层代理
- 考虑真实的场景，对Ingress的使用做了拓展，介绍多path转发及nginx URL重写的实现
浙公网安备 33010602011771号