Kubernetes落地实践之旅
本章学习kubernetes的架构及工作流程，重点介绍如何使用Workload管理业务应用的生命周期，实现服务不中断的滚动更新，通过服务发现和集群内负载均衡来实现集群内部的服务间访问，并通过ingress实现外部使用域名访问集群内部的服务。
学习过程中会逐步对Django项目做k8s改造，从零开始编写所需的资源文件。通过本章的学习，学员会掌握高可用k8s集群的搭建，同时Django demo项目已经可以利用k8s的控制器、服务发现、负载均衡、配置管理等特性来实现生命周期的管理。
纯容器模式的问题
- 业务容器数量庞大，哪些容器部署在哪些节点，使用了哪些端口，如何记录、管理，需要登录到每台机器去管理？
- 跨主机通信，多个机器中的容器之间相互调用如何做，iptables规则手动维护？
- 跨主机容器间互相调用，配置如何写？写死固定IP+端口？
- 如何实现业务高可用？多个容器对外提供服务如何实现负载均衡？
- 容器的业务中断了，如何可以感知到，感知到以后，如何自动启动新的容器?
- 如何实现滚动升级保证业务的连续性？
- …
容器调度管理平台
Docker Swarm Mesos Google Kubernetes
2017年开始Kubernetes凭借强大的容器集群管理功能, 逐步占据市场,目前在容器编排领域一枝独秀
https://kubernetes.io/
架构图
分布式系统，两类角色：管理节点和工作节点
核心组件
-
ETCD：分布式高性能键值数据库,存储整个集群的所有元数据
-
ApiServer: API服务器,集群资源访问控制入口,提供restAPI及安全访问控制
-
Scheduler：调度器,负责把业务容器调度到最合适的Node节点
-
Controller Manager：控制器管理,确保集群资源按照期望的方式运行
- Replication Controller
- Node controller
- ResourceQuota Controller
- Namespace Controller
- ServiceAccount Controller
- Token Controller
- Service Controller
- Endpoints Controller
-
kubelet：运行在每个节点上的主要的“节点代理”，脏活累活
- pod 管理：kubelet 定期从所监听的数据源获取节点上 pod/container 的期望状态（运行什么容器、运行的副本数量、网络或者存储如何配置等等），并调用对应的容器平台接口达到这个状态。
- 容器健康检查：kubelet 创建了容器之后还要查看容器是否正常运行，如果容器运行出错，就要根据 pod 设置的重启策略进行处理.
- 容器监控：kubelet 会监控所在节点的资源使用情况，并定时向 master 报告，资源使用数据都是通过 cAdvisor 获取的。知道整个集群所有节点的资源情况，对于 pod 的调度和正常运行至关重要
-
kube-proxy：维护节点中的iptables或者ipvs规则
-
kubectl: 命令行接口，用于对 Kubernetes 集群运行命令 https://kubernetes.io/zh/docs/reference/kubectl/
工作流程
- 用户准备一个资源文件（记录了业务应用的名称、镜像地址等信息），通过调用APIServer执行创建Pod
- APIServer收到用户的Pod创建请求，将Pod信息写入到etcd中
- 调度器通过list-watch的方式，发现有新的pod数据，但是这个pod还没有绑定到某一个节点中
- 调度器通过调度算法，计算出最适合该pod运行的节点，并调用APIServer，把信息更新到etcd中
- kubelet同样通过list-watch方式，发现有新的pod调度到本机的节点了，因此调用容器运行时，去根据pod的描述信息，拉取镜像，启动容器，同时生成事件信息
- 同时，把容器的信息、事件及状态也通过APIServer写入到etcd中
架构设计的几点思考
- 系统各个组件分工明确(APIServer是所有请求入口，CM是控制中枢，Scheduler主管调度，而Kubelet负责运行)，配合流畅，整个运行机制一气呵成。
- 除了配置管理和持久化组件ETCD，其他组件并不保存数据。意味
除ETCD外其他组件都是无状态的。因此从架构设计上对kubernetes系统高可用部署提供了支撑。 - 同时因为组件无状态，组件的升级，重启，故障等并不影响集群最终状态，只要组件恢复后就可以从中断处继续运行。
- 各个组件和kube-apiserver之间的数据推送都是通过list-watch机制来实现。
实践–集群安装
k8s集群主流安装方式对比分析
- minikube
- 二进制安装
- kubeadm等安装工具
kubeadm https://kubernetes.io/zh/docs/reference/setup-tools/kubeadm/kubeadm/
《Kubernetes安装手册（非高可用版）》
核心组件
静态Pod的方式：
## etcd、apiserver、controller-manager、kube-scheduler
$ kubectl -n kube-system get po
systemd服务方式：
$ systemctl status kubelet
kubectl：二进制命令行工具
理解集群资源
组件是为了支撑k8s平台的运行，安装好的软件。
资源是如何去使用k8s的能力的定义。比如，k8s可以使用Pod来管理业务应用，那么Pod就是k8s集群中的一类资源，集群中的所有资源可以提供如下方式查看：
$ kubectl api-resources
如何理解namespace：
命名空间，集群内一个虚拟的概念，类似于资源池的概念，一个池子里可以有各种资源类型，绝大多数的资源都必须属于某一个namespace。集群初始化安装好之后，会默认有如下几个namespace：
$ kubectl get namespaces
NAME STATUS AGE
default Active 84m
kube-node-lease Active 84m
kube-public Active 84m
kube-system Active 84m
kubernetes-dashboard Active 71m
- 所有NAMESPACED的资源，在创建的时候都需要指定namespace，若不指定，默认会在default命名空间下
- 相同namespace下的同类资源不可以重名，不同类型的资源可以重名
- 不同namespace下的同类资源可以重名
- 通常在项目使用的时候，我们会创建带有业务含义的namespace来做逻辑上的整合
kubectl的使用
类似于docker，kubectl是命令行工具，用于与APIServer交互，内置了丰富的子命令，功能极其强大。 https://kubernetes.io/docs/reference/kubectl/overview/
$ kubectl -h
$ kubectl get -h
$ kubectl create -h
$ kubectl create namespace -h
实践–使用k8s管理业务应用
最小调度单元 Pod
docker调度的是容器，在k8s集群中，最小的调度单元是Pod（豆荚）
为什么引入Pod
-
与容器引擎解耦
Docker、Rkt。平台设计与引擎的具体的实现解耦
-
多容器共享网络|存储|进程 空间, 支持的业务场景更加灵活
使用yaml格式定义Pod
myblog/one-pod/pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: myblog
namespace: luffy
labels:
component: myblog
spec:
containers:
- name: myblog
image: 172.21.51.67:5000/myblog:v1
env:
- name: MYSQL_HOST # 指定root用户的用户名
value: "127.0.0.1"
- name: MYSQL_PASSWD
value: "123456"
ports:
- containerPort: 8002
- name: mysql
image: 172.21.51.67:5000/mysql:5.7-utf8
ports:
- containerPort: 3306
env:
- name: MYSQL_ROOT_PASSWORD
value: "123456"
- name: MYSQL_DATABASE
value: "myblog"
{
"apiVersion": "v1",
"kind": "Pod",
"metadata": {
"name": "myblog",
"namespace": "luffy",
"labels": {
"component": "myblog"
}
},
"spec": {
"containers": [
{
"name": "myblog",
"image": "172.21.51.67:5000/myblog",
"env": [
{
"name": "MYSQL_HOST",
"value": "127.0.0.1"
},
{
"name": "MYSQL_PASSWD",
"value": "123456"
}
],
"ports": [
{
"containerPort": 8002
}
]
},
{
"name": "mysql",
...
}
]
}
}
| apiVersion | 含义 |
|---|---|
| alpha | 进入K8s功能的早期候选版本，可能包含Bug，最终不一定进入K8s |
| beta | 已经过测试的版本，最终会进入K8s，但功能、对象定义可能会发生变更。 |
| stable | 可安全使用的稳定版本 |
| v1 | stable 版本之后的首个版本，包含了更多的核心对象 |
| apps/v1 | 使用最广泛的版本，像Deployment、ReplicaSets都已进入该版本 |
资源类型与apiVersion对照表
| Kind | apiVersion |
|---|---|
| ClusterRoleBinding | rbac.authorization.k8s.io/v1 |
| ClusterRole | rbac.authorization.k8s.io/v1 |
| ConfigMap | v1 |
| CronJob | batch/v1beta1 |
| DaemonSet | extensions/v1beta1 |
| Node | v1 |
| Namespace | v1 |
| Secret | v1 |
| PersistentVolume | v1 |
| PersistentVolumeClaim | v1 |
| Pod | v1 |
| Deployment | v1、apps/v1、apps/v1beta1、apps/v1beta2 |
| Service | v1 |
| Ingress | extensions/v1beta1 |
| ReplicaSet | apps/v1、apps/v1beta2 |
| Job | batch/v1 |
| StatefulSet | apps/v1、apps/v1beta1、apps/v1beta2 |
快速获得资源和版本
$ kubectl explain pod
$ kubectl explain Pod.apiVersion
创建和访问Pod
## 创建namespace, namespace是逻辑上的资源池
$ kubectl create namespace luffy
## 使用指定文件创建Pod
$ kubectl create -f pod.yaml
## 查看pod，可以简写po
## 所有的操作都需要指定namespace，如果是在default命名空间下，则可以省略
$ kubectl -n luffy get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE
myblog 2/2 Running 0 3m 10.244.1.146 k8s-slave1
## 使用Pod Ip访问服务,3306和8002
$ curl 10.244.1.146:8002/blog/index/
## 进入容器,执行初始化, 不必到对应的主机执行docker exec
$ kubectl -n luffy exec -ti myblog -c myblog bash
/ # env
/ # python3 manage.py migrate
$ kubectl -n luffy exec -ti myblog -c mysql bash
/ # mysql -p123456
## 再次访问服务,3306和8002
$ curl 10.244.1.146:8002/blog/index/
Infra容器
登录k8s-slave1节点
$ docker ps -a |grep myblog ## 发现有三个容器
## 其中包含mysql和myblog程序以及Infra容器
## 为了实现Pod内部的容器可以通过localhost通信，每个Pod都会启动Infra容器，然后Pod内部的其他容器的网络空间会共享该Infra容器的网络空间(Docker网络的container模式)，Infra容器只需要hang住网络空间，不需要额外的功能，因此资源消耗极低。
## 登录master节点，查看pod内部的容器ip均相同，为pod ip
$ kubectl -n luffy exec -ti myblog -c myblog bash
/ # ifconfig
$ kubectl -n luffy exec -ti myblog -c mysql bash
/ # ifconfig
pod容器命名: k8s_<container_name>_<pod_name>_<namespace>_<random_string>
查看pod详细信息
## 查看pod调度节点及pod_ip
$ kubectl -n luffy get pods -o wide
## 查看完整的yaml
$ kubectl -n luffy get po myblog -o yaml
## 查看pod的明细信息及事件
$ kubectl -n luffy describe pod myblog
Troubleshooting and Debugging
#进入Pod内的容器
$ kubectl -n <namespace> exec <pod_name> -c <container_name> -ti /bin/sh
#查看Pod内容器日志,显示标准或者错误输出日志
$ kubectl -n <namespace> logs -f <pod_name> -c <container_name>
更新服务版本
$ kubectl apply -f demo-pod.yaml
删除Pod服务
#根据文件删除
$ kubectl delete -f demo-pod.yaml
#根据pod_name删除
$ kubectl -n <namespace> delete pod <pod_name>
Pod数据持久化
若删除了Pod，由于mysql的数据都在容器内部，会造成数据丢失，因此需要数据进行持久化。
-
定点使用hostpath挂载，nodeSelector定点
myblog/one-pod/pod-with-volume.yamlapiVersion: v1 kind: Pod metadata: name: myblog namespace: luffy labels: component: myblog spec: volumes: - name: mysql-data hostPath: path: /opt/mysql/data nodeSelector: # 使用节点选择器将Pod调度到指定label的节点 component: mysql containers: - name: myblog image: 172.21.51.67:5000/myblog:v1 env: - name: MYSQL_HOST # 指定root用户的用户名 value: "127.0.0.1" - name: MYSQL_PASSWD value: "123456" ports: - containerPort: 8002 - name: mysql image: 172.21.51.67:5000/mysql:5.7-utf8 ports: - containerPort: 3306 env: - name: MYSQL_ROOT_PASSWORD value: "123456" - name: MYSQL_DATABASE value: "myblog" volumeMounts: - name: mysql-data mountPath: /var/lib/mysql保存文件为
pod-with-volume.yaml，执行创建## 若存在旧的同名服务，先删除掉，后创建 $ kubectl -n luffy delete pod myblog ## 创建 $ kubectl create -f pod-with-volume.yaml ## 此时pod状态Pending $ kubectl -n luffy get po NAME READY STATUS RESTARTS AGE myblog 0/2 Pending 0 32s ## 查看原因，提示调度失败，因为节点不满足node selector $ kubectl -n luffy describe po myblog Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 12s (x2 over 12s) default-scheduler 0/3 nodes are available: 3 node(s) didn't match node selector. ## 为节点打标签 $ kubectl label node k8s-slave1 component=mysql ## 再次查看，已经运行成功 $ kubectl -n luffy get po NAME READY STATUS RESTARTS AGE IP NODE myblog 2/2 Running 0 3m54s 10.244.1.150 k8s-slave1 ## 到k8s-slave1节点，查看/opt/mysql/data $ ll /opt/mysql/data/ total 188484 -rw-r----- 1 polkitd input 56 Mar 29 09:20 auto.cnf -rw------- 1 polkitd input 1676 Mar 29 09:20 ca-key.pem -rw-r--r-- 1 polkitd input 1112 Mar 29 09:20 ca.pem drwxr-x--- 2 polkitd input 8192 Mar 29 09:20 sys ... ## 执行migrate，创建数据库表，然后删掉pod，再次创建后验证数据是否存在 $ kubectl -n luffy exec -ti myblog python3 manage.py migrate ## 访问服务，正常 $ curl 10.244.1.150:8002/blog/index/ ## 删除pod $ kubectl delete -f pod-with-volume.yaml ## 再次创建Pod $ kubectl create -f pod-with-volume.yaml ## 查看pod ip并访问服务 $ kubectl -n luffy get po -o wide NAME READY STATUS RESTARTS AGE IP NODE myblog 2/2 Running 0 7s 10.244.1.151 k8s-slave1 ## 未重新做migrate，服务正常 $ curl 10.244.1.151:8002/blog/index/ -
使用PV+PVC连接分布式存储解决方案
- ceph
- glusterfs
- nfs
服务健康检查
检测容器服务是否健康的手段，若不健康，会根据设置的重启策略（restartPolicy）进行操作，两种检测机制可以分别单独设置，若不设置，默认认为Pod是健康的。
两种机制：
-
LivenessProbe探针
存活性探测：用于判断容器是否存活，即Pod是否为running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启，如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。... containers: - name: myblog image: 172.21.51.67:5000/myblog:v1 livenessProbe: httpGet: path: /blog/index/ port: 8002 scheme: HTTP initialDelaySeconds: 10 # 容器启动后第一次执行探测是需要等待多少秒 periodSeconds: 10 # 执行探测的频率 timeoutSeconds: 2 # 探测超时时间 ...
-
ReadinessProbe探针
可用性探测：用于判断容器是否正常提供服务，即容器的Ready是否为True，是否可以接收请求，如果ReadinessProbe探测失败，则容器的Ready将为False， Endpoint Controller 控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除，不再将任何请求调度此Pod上，直到下次探测成功。（剔除此pod不参与接收请求不会将流量转发给此Pod）。
最低0.47元/天 解锁文章
扫一扫
3670
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
