Kubernetes 必知必会.docx

《Kubernetes 必知必会.docx》由会员分享，可在线阅读，更多相关《Kubernetes 必知必会.docx（15页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、第7章Kubernetes系列KubernetesMySQL云原生已经愈发变成一个炙手可热的话题，本章收录了爱可生团队在探索MyS QL云原生在K8s上的落地经验；章节包含了 Kubernetes的基础概念和MySQL数据库在落 地云原生过程中的考量和技术提供；Kubernetes学习笔记之基础知识篇 张强一什么是 Kubernetes ?对于订单、交易流水之类的表，常见是应用层会生成订单号、交易流水号之类的唯一编号，DBLE那么是以 这个唯一编号分库分表，而落到MySQL的物理表.匕也是直接以这个编号字段作为表的主键。Kubernetes,又称为k8s （首字母为k、首字母与尾字母之间有8个

2、字符、尾字母为s,所以简称k8s ）或者简称为FkubeJ ,是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务。相 比 与传统部署以及虚拟化部署方式而言，具有如下特点： 敏捷应用程序的创立和部署：与使用VM镜像相比，提高了容器镜像创立的简便性和效率。 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的容器镜像 构建和部署。 关注开发与运维的别离：在构建/发布时而不是在部署时创立应用程序容器镜像，从而将应用程序与 基础架构别离。 可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标 信 号。 跨开发、测试和生产的环境一

3、致性：在便携式计算机上与在云中相同地运行。 跨云和操作系统发行版本的可移植性:可在Ubunlu、RHEL、CoreOS、本地、Google Kubernetes Engine 和其他任何地方运行。 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行OS到使用逻辑资源在OS上运行 应用程序。 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立局部，并且可以动态部署 和管理-而不是在一台大型单机上整体运行。 资源隔离：可预测的应用程序性能。 资源利用：高效率和高密度。479第7章Kubernetes系列ace:default),spec:ports:name: ,po. Sel

4、ector: app=myapp,release=canary Type: ClusterIP IP: 10.96.109.76 Port: 80/TCP TargetPort: 80/TCPEndpoints: 10.244.2.10:80,10.244.3.9:80,10.244.4.10:80 + 2 more. Session Affinity: None Events: 2 .是否能看到Endpoints列且有正常输出?非正常输出那么前往。3 . kubectl port-forward service/ 8080: 成功输出如下： root10-186-65-37 kubectl

5、port-forward service/myapp 8080:80 Forwarding from 127.0.0.1:8080 - 80 Forwarding from :1:8080 - 80.成功那么前往2.3 ,失败那么前往。222 Selector 与 Pod label 比对查看 pod 的 label 信息 kubectl describe pod root10-186-65-37 # kubectl describe pod myapp-deploy-55b54d55b8-5msx8 | grep -i label -A 2 Labels: app=myapp pod-tem

6、plate-hash=55b54d55b8 release=canary查 看 service 的 selector 信 息 kubectl describe service root10-186-65-37 # kubectl describe service myapp | grep -i selecto Selector:app=myapp,release=canary3.比对两者是否正确匹配，错误那么进行修正，正确那么前往223。223检查Pod是否已分配IP查看 pod 的 ip 信息 kubectl describe pod 2.已正确分配ip，那么问题是由于kubectl导致。r

7、oot10-186-65-37kubectl describe pod myapp-deploy-55b54d55b8-5msx8 | grep -iip IP：IPs ：未分配ip ，那么问题是由于Controller manager导致。488第7章Kubernetes系列224 检查 Service TargetPort 与 Pod ContainerPort. 查看 service 的 TargetPort 信息：kubectl describe service root10-186-65-37kubectl describe service myapp | grep -i targe

8、tportTargetPort: 80/TCP1 .查看 pod 的 ContainerPort 信息：kubectl describe pod root010-186-65-37 kubectl describe pod myapp-deploy-55b54d55b8-5msx8 | gr叩-i portPort: 80/TCPHost Port: 0/TCP2 .上方两者一致那么问题是由于kube-proxy导致，不一致那么进行信息修正。23 Ingress模块检查Ingress当前状态检查1. kubectl describe ingress 成功输出如下：root10-186-65-3

9、7 *# kubectl describe ingress ingress-tomcat-tIsName: ingress-tomcat-tlsNamespace: defaultAddress:Default backend: default- -backend:80 ()TLS:tomcat-ingress-secret terminates Rules:Host Path Backends tomcat：8080 (10.244.2.11:8080,10.244.4.11:8080,10.244.5.10:8080)Annotations:kubectl.kubernetes.io/la

10、st-applied-configuration:apiVersion:extensions/vlbetal,kind:Ingress,metadata:annotations:kuberne ts.io/ingress.class:nginx),name:ingress-tomcat-tls/namespace:default/spec:rules:host:tomcat.quan , :paths: backend:serviceName:tomcat/servicePort:8080,path:null,tls:hosts :tomcat.quan ,secretName:tomcat-

11、ingress-secretkubernets.io/ingress.class: nginxEvents: 2.是否能看到backends列且有正常输出？正常输出前往2.3.4 ,否那么前往232。489第7章Kubernetes系列2.32 检查 ServiceName 和 ServicePortkubectl describe ingress 1. kubectl describe senice root10-186-65-37 # kubectl describe ingress ingress-tomcat-tIs | grep -E serviceName|servicePortk

12、ubectl.kubernetes.io/last-applied-configuration:apiVersion:extensions/vlbetal/kindn:Ingress/metadata:annotations:kubernets.io/ingress.class:nginx),name:ingress-tomcat-tls/,namespace:defaulfl/spec:rules:host:tomcat.quan , :paths: backend:serviceName:tomcat,servicePort:8080,path:null,tls:hosts :tomcat

13、.quan /secretName:tomcat-ingress-secret3.检查前两者的ServiceName和ServicePort书写是否正确，假设正确那么前往2.3.3,错误请修正。23.3 Ingress controller 文档.问题是由于 Ingress controller 导致，请查阅文档寻找解决方法： s:/kubcrnetes.io/docs/concepts/ser vices-nelworking/ingress-controllers/23.4 检查 port-forward ingresskubectl port-forward 8080: 测试是否能正常访

14、问:curl localhost:80 80可正常访问前往2.3.5 ,否那么前往2.3.3 o检查能否在外网通过Ingress进行访问1 .可从外网成功访问，故障排查结束。2 .假设无法从外网访问，那么问题是由于基础设施(infrastruclure)或集群暴露(exposed)方式导致，请排 查。490第7章Kubernetes系列7.3 kubernetes环境测试部署MySQL的随想 王悦注：阅读本文需要了解pod, controller, service等一些kubernetes的基本概念。什么是kubernetes ?有了容器技术后为什么还需要kubernetes ?容器凭借其良好

15、的移植性，敏捷性和革命性的打包方式迅速成为云服务的新基础设施。但Docker毕竟只 是containerruntime,我们需要一个编排框架作为系统核心来串联开发、测试、部署、运维等整个软 件生命周期。kubernetes就提供这样一个框架，提供大量容器的部署、编排、管理的能力。如果将MySQL部署在kubernetes会有哪些挑战？带来了什么收益？虽然kubernetes社区一直在努力使得有状态应用成为一等公民，也推出 了 statefulset控制器支持pod的 顺序部署，稳定的域名访问和存储访问。但鉴于MySQL部署运维的多样性和复杂性，在kubernetes上部 署MySQL仍然要面临

16、众多挑战。1、业务流量入口的配置方式传统虚拟机环境下，我们通过虚IP的方式，让业务应用都配置事先定义的一个虚IP为链 接数据库的地址，然后由高可用服务保证虚IP始终能被路由到master数据库。在kubern etes中，出现了一层网络插件屏蔽了底层网络拓扑，高可用服务管理虚IP的方式需要随之 适应调整，比方通过service结合标签完成虚IP的漂移，但service本身是kubernetes提 供的一项功能，其可靠性和性能都取决于kubernetes服务的稳定。以性能来说，service是 kubc proxy组件通过配置iptables实现的，当iptablcs规那么较多时不可防止的会产生

17、时 延，需要我们针对性的解决。2、容器隔离带来的监控视野问题在kubernetes中，如果将MySQL制作为container运行在一个pod中，container会将MySQL进程和 运行环境隔离在一个单独的namespace中。监控组件在获取MySQL的一些mctirc时，可能不得不进入 与MySQL同一个namespace中，在部署和设计监控组件时需要考虑到这些限制。3、存储在kubernetes中，支持配置各种不同的存储。如果使用本地存储local persistent volume,那么需要绑定 MySQL在一个固定的节点，这就完全浪费了 kubernetes灵活调度的天然优势；而如

18、果使用远程共享存储， 确实是将MySQL进程与其存储完全解耦，使得MySQL进程可以在任意节点调度，然而考虑到高I/O吞 吐量的情况，就不是那么美好了。设计时需要考量远程存储是否能够满足MySQL的带宽要求。4、高可用/备份恢复491第7章Kubernetes系列7.3 kubernctes环境测试部署MySQL的随想 kubemetes提供的statefulset控制器只能提供最基本的部署，删除功能，无法实现完善的MySQL集群高 可用/备份恢复操作。对于有状态应用的部署，仍需要定制开发，所以多数公司提供了定制的operator来完 成应用容器的管理。比方etcd operator, MyS

19、QL operator,后文将为大家详述我测试使用MySQL o perator 的一些记录。注：operator是CoreOS推出的旨在简化复杂有状态应用管理的框架，我们可以通过operator自定义一 个有状态应用容器的控制器，operator通过kubernetes API观察集群现有状态，管理集群行为，以到达 用户期望的集群状态。说完了问题和挑战，我们来说说收益。把MySQL塞进kubernetes生态带来了什么？1 .丰富的网络配置结合kubernetes的cni网络插件可以快速实现限流，黑白名单.各类kubernetes调度、运维功能敏捷部署，滚动更新，依据负载情况的节点调度.与同

20、样部署在kubernetes生态的业务应用紧密配合然而考虑到MySQL这类持久层软件的特殊性，不能简单的套用kubernetes的原生API功能，比方 滚动更新需要考虑主从角色的先后顺序，配套高可用软件在MySQL更新阶段的行为，业务流量的切 换等等。这些在传统环境中已经解决的问题在kubernetes中仍然需要被重新规划解决方案。控制器介绍鉴于以上种种挑战，在kubernetes上管理MySQL需要一套专为MySQL设计的控制器（就我们前面说 到的operator）,目前开源社区中比拟流行的有以下两个控制器：1、Oracle MySQL operator先简单过一遍功能：1 .最低支持版本.

21、只能支持部署MySQL Group Replication架构，不支持Master-Slave部署2 . operator自动建的service无法区分读写节点，推荐应用使用mysql router,由mysql router路由 至下游实例.提供mysqldump （不支持其他备份工具）配置定时备份，备份文件上传远程存储，目前仅实现了 AWS S3接口3 .支持从远程存储中获取备份执行回放还原. operator内置提供了一些基础metric监控集群状态注：具体的安装步骤就不在这里详述了，大家可以参考， s:/github /oracle/MySQL-operator/blob/master

22、/docs/tutorial.md492第7章Kubernetes系列下面探索一下operator部署时的一些实现方式：1. operator 监听用户定义的配置 cr 调用 kubernetes 叩i 创立 statefulset 来部署 MySQL Group Replicat ion集群使用kubernetes secret存储和管理root密码2. statefulset创立的pod中定义两个container, 一个容纳mysqld进程，一个容纳以sidecar的模式 负责运维功能的mysqlagent进程mysqld作为容器的1号进程，由kubernetes负责守护3. mysql

23、 agent进程负责mysqld的状态监控，备份和回放任务的执行，opertaor的metric也是由其 提供FAQ:Q： pod重启后能否保证实例的数据不丧失？A： operator在创立实例时会将datadir配置为mysqlvokime挂载（如pvc或emptydir）,所以实例重启 后能够重新挂载恢复数据。注：限制是用户不能自定义data, binlog, redolog目录，如果不在默认的 /var/lib/mysql目录中，数据会随pod重启而消亡Q：可以为mysqld container设置epu, mem资源限制吗？A：可以在创立集群时配置限制，但该功能只在master版本上存

24、在，目前helmhub中使用的是O.3.Otag 版本，该版本中无该功能Q：业务和实例不在一个kubernetes集群时该如何连接？A：在实例所在集群上先部署一个mysql-router,然后通过暴露mysql-router给外部集群来提供访问。暴 露方式有多种可选，如 NodePort. LoadBalancer, Ingress 等。可见Oracle MySQL operator提供的功能非常基础，而且其github仓库已经一年多没有维护了，官方好像 不是很想推动MySQL上kubernetes,毕竟传统云服务提供的RDS服务已经能够满足大局部用户场景。2、Percona MySQL op

25、erator另外，Percona也提供了一个MySQL的operator,能够部署高可用master-slave结构的MySQL,但依 托于Percona版的MySQL提供的功能，并不支持原生的MySQL镜像。结语使用operator运维有状态应用确实能够解决多数问题，但维护数据库应用本身就是复杂困难的，需要适 应很多场景，在kubernetes上完全解决这些问题短期内非常困难。上述两个MySQL operator目前的实 现都相对基础，直接在生产环境部署的稳定性也没有保障，只能作为调研测试的对象。493第7章Kubernetes系列7.4 kubernetes operator 简 介 沈亚

26、军k8s operator 介绍k8s Operator是一种用特定应用的控制器，可扩展Kubernetes API的功能，来代表k8s用户创立、配 置和管理复杂应用的实例，它基于基本k8s资源和控制器概念构建，但又涵盖了特定领域或应用的知识， 用于实现其所管理的应用生命周期的自动化，常见的有ctcd-opcrator promcthcus-opcrator以下是k8soperator执行的一些最常见功能的列表： 部署指定配置和数量的应用 对应用进行扩缩容 启动升级、自动备份和故障恢复 执行任何其他可以作为代码呈现的管理应用的任务operator工作原理k8soperator是使用自定义资源(

27、CR)管理应用及其组件的臼定义k8s控制器，自定义资源是k8s中的API 扩展机制。自定义资源定义(CRD)会声明CR并列出Operator用户可用的所有配置 当operator被部署到k8s集群中会通过连接master节点的API server监听特定资源类型的事件并基于 用户在CR中提供的配置和嵌入在operator处理逻辑采取对应的操作，进行循环处理确保当前该资源的状 态与理想状态相符编写一个简单的operatoroperator SDK是CoreOS公司开发和维护的用快速创立operator的工具，可以帮助我们快速构建ope rator应用，类似的工具还有： KUDO (Kuberne

28、tes 通用声明式 Operator) kubebuilder, kubernetes SIG 在维护的一个工程 Metacontroller,可与Webhook结合使用，以实现自己的功能接下来会使用operator-sdk构建一个简单的operator工程开发环境：494第7章Kubernetes系列golang 1.16.3 kubernetes 1.19 macOS 11.41、使用 operator-sdk CLI 创立 nginx-operator 工程mkdir -p $HOME/nginx-operator & cd $HOME/nginx-operator operator-s

29、dk init -domain example -repo github /example/nginx-operator2、创立新的CRD API指定组为proxy类型为Nginx版本为vlalphaloperator-sdk create api -group proxy -version vlalphal -kind Nginx -resource - controller该命令生成的 api/v 1 alpha I/nginx_types.go 和 controllers/nginx_con(roller.go 文件是需要我们分别实现 CR 的配置和控制器的处理逻辑3、定义Nginx资源

30、类型CR并生成CRD修改文件 api/v I alpha 1 /nginx_lypes.go 中的 NginxSpec 和 NginxStatus 如下/ NginxSpec defines the desired state of Nginx type NginxSpec struct Count int32 json:count / NginxStatus defines the observed state of Nginx type NginxStatus struct / Nodes are the names of the nginx pods Nodes string json:

31、nodes执行下面的命令生成CR资源相关代码，每次修改CR的定义都需执行该命令make generate执行下面的命令会生成 CRD 定义文件 nginx-operator/config/crd/bases/proxy.example _nginxes.yaml make manifests4、控制器处理逻辑实现需要在 controllers/nginx_controller.go 实现以下逻辑，可参考：( s:/giihub /nufy323/nginx-sample-oper ator/blob/main/controllers/nginx_controller.go)实现SelupWil

32、hManager方法设置要监听的资源对象，如下代码中指定了主要监听对象为Nginx,次要监 听对象为Deployment：495第7章Kubernetes系列func (r *NginxReconciler) SetupWithManager(mgr Ctrl.Manager) error return ctrl.NewControllerManagedBy(mgr).For(&proxyvlalphal.Nginx).Owns(&appsvl.Deployment). Complete(r) )Reconcile方法中用来维护前k8s环境中监听的对象使其到达预期的状态，每当被监听的资源对象触

33、发新 的事件该方法会被调用func (r *NginxReconciler) Reconcile(ctx context.Context, req Ctrl.Request) (ctrl.Result, error) log := ctrllog.FromContext(ctx)return Ctrl.Result, nil )5、部署 operatorI.编译并部署operator镜像 修改Makefile-IMG ?= controller:latest+IMG ?= $(IMAGE_TAG_BASE)：$(VERSION)编译并部署operator到k8s集群make docker-bu

34、ild make deploy.查看 deployment$ kubectl get deployment -n nginx-operator-system NAMEREADY UP-TO-DATE AVAILABLE AGEnginx-operator-controller-manager 1/1115ml4s2 .创立 Nginx CR 修改文件 config/samples/proxy_v I alpha I _nginx.yaml 如下:apiVersion: kind: Nginx metadata: name: nginx-samplespec: count: 3执行命令 kube

35、ctl apply -f config/samples/proxy_vlalphal_nginx.yaml 创立 CR 获取创立的pod$ kubectl get podsNAMEREADY STATUS RESTARTS AGE497第7章Kubernetes系列nginx-sample-66b6c48dd5-bcqc81/1Running015mnginx-sample-66b6c48dd5-thnx61/1Running015mnginx-sample-66b6c48dd5-xrd911/1Running015m3 .检查CR的状态$ kubectl get nginx/nginx-sa

36、mple -o yaml apiVersion: kind: Nginx metadata:name: nginx-sample namespace: default spec* count: 3status: nodes: -nginx-sample-66b6c48dd5-bcqc8 -nginx-sample-66b6c48dd5-thnx6假设需要清理执行以下命令kubectl delete -f config/samples/proxy_vlalphal_nginx.yaml497第7章Kubernetes系列1. Docker的兴起要说Kubernetes,还要从docker容器化技

37、术谈起。2013年，Docker公司(彼时还称之为dolCloud Inc.)在PyCon大会上首次公开介绍/ Docker这一产品。 当时最热门的PaaS工程是Cloud Foundaiy,然而Docker工程在docker镜像上的优秀设计，解决了当 时其他PaaS技术未能解决的应用打包和应用发布的繁琐步骤问题。大多数docker镜像是直接由一个完整 操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完 全一样的一一正是这一优秀的特性使得docker工程在众多Pass技术迅速崛起。2. Docker编排的进化Swarm的最大特点，是完全使用Docker

38、工程原本的容器管理API来完成集群管理。在部署了 Swarm的 多机环境下，用户只需要使用原先的Docker指令创立一个容器，这个请求就会被Swarm拦截下来处理, 然后通过具体的调度算法找到一个合适的Docker Daemon运行起来。2014年，docker并购Fig工程，将其开展为现在的Compose,使得容器的部署更加的便利 可以 使用配置文件就可以完成较为复杂的容器的编排参数的配置。同年6月，Google公司发布了 KubemeteSo2015年6月22日，由Docker公司牵头，CoreOS Google. RedHat等公司共同宣布，Docker公司将 Libcontainer捐

39、出，并改名为RunC工程，交由一个完全中立的基金会管理，然后以RunC为依据，大家 共同制定套容器和镜像的标准和规范。这套标准和规范，就是OCI ( Open Container Initiative)o OCI的提出，意在将容器运行时和镜像的实现从Docker工程中完全剥离出来。从API到容器运行 时的每一层，Kubernetes工程都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入到 Kubernetes工程的每一个阶段。Kubernetes工程的这个变革的效果立竿见影，很快在整个容器社区中催生 出了大量的、基于Kubernetes API和扩展接口的二次创新工作，比方： 微

40、服务治理工程Istio； 有状态应用部署框架Operator；还有像Rook这样的开源创业工程，它通过Kubernetes的可扩展接口，把Ceph这样的重量级 产品封装成了简单易用的容器存储插件。二.Docker容器的技术基础1 进程与 Linux Namespaces为了到达在容器中排除其他进程，docker利用了 Linux的Namespace机制。在Linux系统中创立线程 的系统调用是clone。，比方：int pid = clone(main_function, stack_size, SIGCHLD, NULL);此时，这个系统调用就会为我们创立一个新的进程，并且返回它的进程号pi

41、do而如果在用cloneO系统 调用创立一个新进程时，加入CLONE.NEWPID参数，比方：480第7章Kubernetes系列int pid = clone(main_function, stack_size, CLONE_NEWPID | SIGCHLD, NULL);此时这个进程就会在一个全新的进程空间里，在这个进程空间里，它的pid是I。除去PID Namespac e, Linux系统还提供了 Mounts UTS IPC New work和User等Namespace。这就是为什么容器中只能看 到自身容器内的进程的原因了。2资源限制与Linux Cgroups虽然在容器中PID为

42、1的进程只能看到容器里的情况。但是从宿主机角度来看，它作为一个普通进程与 其他进程依然是平等关系，也就说它能够使用的资源(CPU、内存等)，仍旧可以被宿主机上的其他进程 占用。这种情况导致了容器内的进程I隔离了但没有完全隔离的尴尬，是不符合容器作为一个沙盒 的特性的。Linux Cgroups的全称是Linux Control Groups。它的最主要作用，就是限制,个进程组能够使 用的资源上限，包括CPU、内存、磁盘、网络带宽等。比方： blkio,为块设备设定I/O限制，一般用于磁盘等设备； cpuset,为进程分配单独的CPU核和对应的内存节点； memory,为进程设定内存使用的限制。

43、等等 凭借Cgroups的机制，容器化技术可以完成对容器内进程的资源限制。3.容器镜像和文件系统Linux操作系统中有一个名为chroot的命令，作用就是改变进程的根Fl录到指定的位置。比方执行chroot SHOME/lesi/bin/bash之后，如果执行】s / ,就会看到命令返I可的内容都是SHOME/test目录下的内 容。Linux操作系统的第一个Namespace是Mount Namespace,正是基于chroot的不断改良而来的。为了让容器中的目录看起来更真实，一般会在容器内的根目录下挂载一个完整操作系统的文件系 统。比方Ubuntu 16.04的ISO。这样在启动容器后，在

44、容器内执行1s/查看根目录下的内容，就是Ubuntu 16.04的所有目录和文件。这个挂载在容器根目录上、用来为容器进程提供隔离后执行环境的文件系统， 就是所谓的容器镜像，也称之为rootfs (根文件系统)。所以，对于Docker来说，核心流程即：1 .启用 Linux Namespace 配置；.设置指定的Cgroups参数：2 .切换进程的根目录(pivot_root或chroot)。同时需要注意：roolfs只是一个操作系统所包含的文件、配置和目录，并不包含Linux操作系统内核。 所有的容器，都共享宿主机操作系统的内核。综上，一个容器，实际上是一个由Linux Namespace. Linux Cgroups和rootfs三种技术构建出来的进程的隔离环境。可以分为两局部： 容器镜像，印联合挂载在/var/lib/docker/aufs/mnt上的rootfs CR1-0等多个容器运行环境。以上设计的考量是Ku