周泽改优秀作者
原创内容 来源:小居数码网 时间:2024-08-17 15:15:01 阅读() 收藏:51 分享:64 爆
导读:您正在阅读的是关于【数码知识】的问题,本文由科普作家协会,生活小能手,著名生活达人等整理监督编写。本文有5832个文字,大小约为23KB,预计阅读时间15分钟。
为什么要学习 Kubernetes?虽然 Docker 已经很强大了,但是在实际使用上还是有诸多不便,比如集群管理、资源调度、文件管理等等。在这样一个百花齐放的容器时代涌现出了很多解决方案,比如 Mesos、Swarm、Kubernetes 等等,其中谷歌开源的 Kubernetes 是作为老大哥的存在。也可参考:k8s 和 Docker 关系简单说明
kubernetes 已经成为容器编排领域的王者,它是基于容器的集群编排引擎,具备扩展集群、滚动升级回滚、弹性伸缩、自动治愈、服务发现等多种特性能力。
Kubernetes 的出现不仅主宰了容器编排的市场,更改变了过去的运维方式,不仅将开发与运维之间边界变得更加模糊,而且让 DevOps 这一角色变得更加清晰,每一个软件工程师都可以通过 Kubernetes 来定义服务之间的拓扑关系、线上的节点个数、资源使用量并且能够快速实现水平扩容、蓝绿部署等在过去复杂的运维操作。
主要介绍学习一些什么知识
传统的客户端服务端架构
Kubernetes 遵循非常传统的客户端/服务端的架构模式,客户端可以通过 RESTful 接口或者直接使用 kubectl 与 Kubernetes 集群进行通信,这两者在实际上并没有太多的区别,后者也只是对 Kubernetes 提供的 RESTful API 进行封装并提供出来。每一个 Kubernetes 集群都是由一组 Master 节点和一系列的 Worker 节点组成,其中 Master 节点主要负责存储集群的状态并为 Kubernetes 对象分配和调度资源。
作为管理集群状态的 Master 节点,它主要负责接收客户端的请求,安排容器的执行并且运行控制循环,将集群的状态向目标状态进行迁移。Master 节点内部由下面三个组件构成:
API Server: 负责处理来自用户的请求,其主要作用就是对外提供 RESTful 的接口,包括用于查看集群状态的读请求以及改变集群状态的写请求,也是唯一一个与 etcd 集群通信的组件。
etcd: 是兼具一致性和高可用性的键值数据库,可以作为保存 Kubernetes 所有集群数据的后台数据库。
Scheduler: 主节点上的组件,该组件监视那些新创建的未指定运行节点的 Pod,并选择节点让 Pod 在上面运行。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。
controller-manager: 在主节点上运行控制器的组件,从逻辑上讲,每个控制器都是一个单独的进程,但是为了降低复杂性,它们都被编译到同一个可执行文件,并在一个进程中运行。这些控制器包括:节点控制器(负责在节点出现故障时进行通知和响应)、副本控制器(负责为系统中的每个副本控制器对象维护正确数量的 Pod)、端点控制器(填充端点 Endpoints 对象,即加入 Service 与 Pod))、服务帐户和令牌控制器(为新的命名空间创建默认帐户和 API 访问令牌)。
其他的 Worker 节点实现就相对比较简单了,它主要由 kubelet 和 kube-proxy 两部分组成。
kubelet: 是工作节点执行操作的 agent,负责具体的容器生命周期管理,根据从数据库中获取的信息来管理容器,并上报 pod 运行状态等。
kube-proxy: 是一个简单的网络访问代理,同时也是一个 Load Balancer。它负责将访问到某个服务的请求具体分配给工作节点上同一类标签的 Pod。kube-proxy 实质就是通过操作防火墙规则(iptables或者ipvs)来实现 Pod 的映射。
Container Runtime: 容器运行环境是负责运行容器的软件,Kubernetes 支持多个容器运行环境: Docker、 containerd、cri-o、 rktlet 以及任何实现 Kubernetes CRI(容器运行环境接口)。
主要介绍关于 K8s 的一些基本概念
主要由以下几个核心组件组成:
除了核心组件,还有一些推荐的插件:
以上内容参考链接: https:// 重新将时间调整正确,重新启动 etcd,发现还是起不来,报错如下:
Mar 05 14:27:15 k8s-node2 etcd[3248]: etcd Version: 3.3.13Mar 05 14:27:15 k8s-node2 etcd[3248]: Git SHA: 98d3084Mar 05 14:27:15 k8s-node2 etcd[3248]: Go Version: go1.10.8Mar 05 14:27:15 k8s-node2 etcd[3248]: Go OS/Arch: linux/amd64Mar 05 14:27:15 k8s-node2 etcd[3248]: setting maximum number of CPUs to 4, total number of available CPUs is 4Mar 05 14:27:15 k8s-node2 etcd[3248]: the server is already initialized as member before, starting as etcd member...Mar 05 14:27:15 k8s-node2 etcd[3248]: peerTLS: cert = /opt/etcd/ssl/server.pem, key = /opt/etcd/ssl/server-key.pem, ca = , trusted-ca = /opt/etcd/ssl/ca.pem, client-cert-auth = false, crl-file =Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for peers on https://192.168.25.226:2380Mar 05 14:27:15 k8s-node2 etcd[3248]: The scheme of client url http://127.0.0.1:2379 is HTTP while peer key/certfiles are presented. Ignored key/cert files.Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 127.0.0.1:2379Mar 05 14:27:15 k8s-node2 etcd[3248]: listening for client requests on 192.168.25.226:2379Mar 05 14:27:15 k8s-node2 etcd[3248]: member 9c166b8b7cb6ecb8 has already been bootstrappedMar 05 14:27:15 k8s-node2 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILUREMar 05 14:27:15 k8s-node2 systemd[1]: Failed to start Etcd Server.Mar 05 14:27:15 k8s-node2 systemd[1]: Unit etcd.service entered failed state.Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service failed.Mar 05 14:27:15 k8s-node2 systemd[1]: etcd.service holdoff time over, scheduling restart.Mar 05 14:27:15 k8s-node2 systemd[1]: Starting Etcd Server...Mar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_NAME, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_DATA_DIR, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_PEER_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_LISTEN_CLIENT_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_ADVERTISE_PEER_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_ADVERTISE_CLIENT_URLS, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER, but unused: shadowedby corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_TOKEN, but unused: shadowed by corresponding flagMar 05 14:27:15 k8s-node2 etcd[3258]: recognized environment variable ETCD_INITIAL_CLUSTER_STATE, but unused: shadowed by corresponding flag
解决方法:
检查日志发现并没有特别明显的错误,根据经验来讲,etcd 节点坏掉一个其实对集群没有大的影响,这时集群已经可以正常使用了,但是这个坏掉的 etcd 节点并没有启动,解决方法如下:
进入 etcd 的数据存储目录进行备份 备份原有数据:
cd /var/lib/etcd/default.etcd/member/cp * /data/bak/
删除这个目录下的所有数据文件
rm -rf /var/lib/etcd/default.etcd/member/*
停止另外两台 etcd 节点,因为 etcd 节点启动时需要所有节点一起启动,启动成功后即可使用。
#master 节点systemctl stop etcdsystemctl restart etcd#node1 节点systemctl stop etcdsystemctl restart etcd#node2 节点systemctl stop etcdsystemctl restart etcd
在每台服务器需要建立主机互信的用户名执行以下命令生成公钥/密钥,默认回车即可
ssh-keygen -t rsa
可以看到生成个公钥的文件。
互传公钥,第一次需要输入密码,之后就OK了。
ssh-copy-id -i /root/.ssh/id_rsa.pub root@192.168.199.132 (-p 2222)
-p 端口 默认端口不加-p,如果更改过端口,就得加上-p. 可以看到是在.ssh/下生成了个 authorized_keys的文件,记录了能登陆这台服务器的其他服务器的公钥。
测试看是否能登陆:
ssh 192.168.199.132 (-p 2222)
hostnamectl set-hostname k8s-master1
如果不安装或者不输出,可以将 update 修改成 install 再运行。
yum install updateyum update kernelyum update kernel-develyum install kernel-headersyum install gccyum install gcc make
运行完后
sh VBoxLinuxAdditions.run
可以通过下面命令强制删除
kubectl delete pod NAME --grace-period=0 --force
删除namespace一直处于Terminating状态
可以通过以下脚本强制删除
[root@k8s-master1 k8s]# cat delete-ns.sh#!/bin/bashset -euseage(){ echo "useage:" echo " delns.sh NAMESPACE"}if [ $# -lt 1 ];then useage exitfiNAMESPACE=$1JSONFILE=${NAMESPACE}.jsonkubectl get ns "${NAMESPACE}" -o json > "${JSONFILE}"vi "${JSONFILE}"curl -k -H "Content-Type: application/json" -X PUT -->容器包含有效的 CPU/内存 requests 且没有指定 limits 可能会出现什么问题?</h1><p>下面我们创建一个对应的容器,该容器只有 requests 设定,但是没有 limits 设定,</p><pre><code>- name: busybox-cnt02 image: busybox command: ["/bin/sh"] args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"] resources: requests: memory: "100Mi" cpu: "100m"
这个容器创建出来会有什么问题呢?
其实对于正常的环境来说没有什么问题,但是对于资源型 pod 来说,如果有的容器没有设定 limit 限制,资源会被其他的 pod 抢占走,可能会造成容器应用失败的情况。可以通过 limitrange 策略来去匹配,让 pod 自动设定,前提是要提前配置好limitrange 规则。
来源:https:///passzhang
Kubernetes 上对应用程序进行故障排除的 6 个技巧 推荐给大家,日常排错必备。分享一份阿里云内部超全K8s实战手册,免费下载!
一个目标:容器操作;两地三中心;四层服务发现;五种 Pod 共享资源;六个 CNI 常用插件;七层负载均衡;八种隔离维度;九个网络模型原则;十类 IP 地址;百级产品线;千级物理机;万级容器;相如无亿,k8s 有亿:亿级日服务人次。
一个目标:容器操作
Kubernetes(k8s)是自动化容器操作的开源平台。这些容器操作包括:部署、调度和节点集群间扩展。
下面是 k8s 的架构拓扑图:
两地三中心
两地三中心包括本地生产中心、本地灾备中心、异地灾备中心。
两地三中心要解决的一个重要问题就是数据一致性问题。
k8s 使用 etcd 组件作为一个高可用、强一致性的服务发现存储仓库。用于配置共享和服务发现。
它作为一个受到 Zookeeper 和 doozer 启发而催生的项目。除了拥有他们的所有功能之外,还拥有以下 4 个特点:
四层服务发现
先一张图解释一下网络七层协议:
k8s 提供了两种方式进行服务发现:
以上两种方式,一个是基于 TCP,DNS 基于 UDP,它们都是建立在四层协议之上。
五种 Pod 共享资源
Pod 是 k8s 最基本的操作单元,包含一个或多个紧密相关的容器。
一个 Pod 可以被一个容器化的环境看作应用层的“逻辑宿主机”;一个 Pod 中的多个容器应用通常是紧密耦合的,Pod 在 Node 上被创建、启动或者销毁;每个 Pod 里运行着一个特殊的被称之为 Volume 挂载卷,因此他们之间通信和数据交换更为高效。在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个 Pod 中。
同一个 Pod 里的容器之间仅需通过 localhost 就能互相通信。
一个 Pod 中的应用容器共享五种资源:
Pod 的生命周期通过 Replication Controller 来管理;通过模板进行定义,然后分配到一个 Node 上运行,在 Pod 所包含容器运行结束后,Pod 结束。
Kubernetes 为 Pod 设计了一套独特的网络配置,包括为每个 Pod 分配一个IP地址,使用 Pod 名作为容器间通信的主机名等。
六个 CNI 常用插件
CNI(Container Network Interface)容器网络接口是 Linux 容器网络配置的一组标准和库,用户需要根据这些标准和库来开发自己的容器网络插件。CNI 只专注解决容器网络连接和容器销毁时的资源释放,提供一套框架。所以 CNI 可以支持大量不同的网络模式,并且容易实现。
下面用一张图表示六个 CNI 常用插件:
提负载均衡就不得不先提服务器之间的通信。
IDC(Internet Data Center)也可称数据中心、机房,用来放置服务器。IDC 网络是服务器间通信的桥梁。
上图里画了很多网络设备,它们都是干啥用的呢?
路由器、交换机、MGW/NAT 都是网络设备,按照性能、内外网划分不同的角色。
先说说各层负载均衡:
这里用一张图来说说四层和七层负载均衡的区别:
上面四层服务发现讲的主要是 k8s 原生的 kube-proxy 方式。k8s 关于服务的暴露主要是通过 NodePort 方式,通过绑定 minion 主机的某个端口,然后进行 Pod 的请求转发和负载均衡,但这种方式有下面的缺陷:
理想的方式是通过一个外部的负载均衡器,绑定固定的端口,比如 80;然后根据域名或者服务名向后面的 Service IP 转发。
Nginx 很好的解决了这个需求,但问题是如果有的新的服务加入,如何去修改并且加载这些 Nginx 配置?
Kubernetes 给出的方案就是 Ingress。这是一个基于七层的方案。
八种隔离维度
k8s 集群调度这边需要对上面从上到下、从粗粒度到细粒度的隔离做相应的调度策略。
九个网络模型原则
k8s 网络模型要符合四个基础原则、三个网络要求原则、一个架构原则、一个 IP 原则。
每个 Pod 都拥有一个独立的 IP 地址,而且假定所有 Pod 都在一个可以直接连通的、扁平的网络空间中,不管是否运行在同一 Node 上都可以通过 Pod 的 IP 来访问。
k8s 中的 Pod 的 IP 是最小粒度 IP。同一个 Pod 内所有的容器共享一个网络堆栈,该模型称为 IP-per-Pod 模型。
IP-per-Pod 模型从端口分配、域名解析、服务发现、负载均衡、应用配置等角度看,Pod 可以看做是一台独立的虚拟机或物理机。
要符合下面的架构:
由上图架构引申出来 IP 概念从集群外部到集群内部:
十类IP地址
大家都知道 IP 地址分为 ABCDE 类,另外还有五类特殊用途的 IP。
第一类
A 类:1.0.0.0-1226.255.255.255,默认子网掩码/8,即255.0.0.0。B 类:128.0.0.0-191.255.255.255,默认子网掩码/16,即255.255.0.0。C 类:192.0.0.0-223.255.255.255,默认子网掩码/24,即255.255.255.0。D 类:224.0.0.0-239.255.255.255,一般用于组播。E 类:240.0.0.0-255.255.255.255(其中255.255.255.255为全网广播地址)。E 类地址一般用于研究用途。
第二类
0.0.0.0严格来说,0.0.0.0 已经不是一个真正意义上的 IP 地址了。它表示的是这样一个集合:所有不清楚的主机和目的网络。这里的不清楚是指在本机的路由表里没有特定条目指明如何到达。作为缺省路由。127.0.0.1 本机地址。
第三类
224.0.0.1 组播地址。如果你的主机开启了IRDP(internet路由发现,使用组播功能),那么你的主机路由表中应该有这样一条路由。
第四类
169.254.x.x使用了 DHCP 功能自动获取了 IP 的主机,DHCP 服务器发生故障,或响应时间太长而超出了一个系统规定的时间,系统会为你分配这样一个 IP,代表网络不能正常运行。
第五类
10.xxx、172.16.x.x~172.31.x.x、192.168.x.x 私有地址。大量用于企业内部。保留这样的地址是为了避免亦或是哪个接入公网时引起地址混乱。
上面就是小居数码小编今天给大家介绍的关于(k8s很难学吗)的全部内容,希望可以帮助到你,想了解更多关于数码知识的问题,欢迎关注我们,并收藏,转发,分享。
94%的朋友还想知道的:
(374)个朋友认为回复得到帮助。
部分文章信息来源于以及网友投稿,转载请说明出处。
本文标题:k8s从入门到放弃(k8s很难学吗):http://sjzlt.cn/shuma/156457.html