当前位置:首页 > 数码 > Kubernetes-部署和保养常见疑问汇总 (kubernetes与docker的关系)

Kubernetes-部署和保养常见疑问汇总 (kubernetes与docker的关系)

admin5个月前 (05-04)数码25

集群疑问

系统

Error:unknownflag:--etcd-quorum-read

删除service外面的相应字段

startrequestrepeatedtooquicklyforkube-apiserver.service

检查是不是有之前的进程占用,而后将service字段抠进去手动启动检查可否成功,也可显示失误

healthcheckforpeeracd2ba924953b1eccouldnotconnect:dialtcp192.168.81.60:2380:getsockopt:connectionrefused

剖析是由于etcd1的性能文件/etc/etcd/etcd.conf中的ETCD_INITIAL_CLUSTER_STATE是new,而在性能中ETCD_INITIAL_CLUSTER写入了etcd2/3的IP:PORT,这时etcd1尝试去衔接etcd2、etcd3,但是etcd2、3的etcd服务此时还未启动,因此要求先启动etcd2和3的etcd服务,再去启动etcd1。

dialtcp127.0.0.1:2379:getsockopt:connectionrefused

etcd.confETCD_LISTEN_CLIENT_URLS选项中参与`

Unabletoconnecttotheserver:x509:certificateisvalidforetcd1,etcd2,node1,node2,kubees,kubernetes.default,kubernetes.default.svc,kubernetes.default.svc.cluster,kubernetes.default.svc.cluster.local,notk8s1

修正/root/cfssl/kubernetes/kubernetes-server-csr.json参与失误中的k8s

FledatstepCHDIRspawning/usr/local/bin/kubelet:Nosuchfileordirectory

mkdir/var/lib/kubelet(详细看service外面WorkingDirectory)

failedtorunKubelet:misconfiguration:kubeletcgroupdriver:"systemd"isdifferentfromcgroupdriver:"cgroupfs"

vim/usr/lib/systemd/system/docker.serviceExecStart=/usr/local/bin/dockerd--exec-optnative.cgroupdriver=systemd详细依照报错修正

etcdclusterisunavailableormisconfigured;error#0:dialtcp127.0.0.1:4

vim/etcd/etcd/etcd.confETCD_LISTEN_CLIENT_URLS=

master形态flanned反常pod外部通讯相互ping通node形态宿主机能ping通百度容器能ping宿主机svc

现象

容器不能ping百度

kubectlrun-it--rm-test--image=busybox:1.28.4sh测试dns

Errorregisteringnetwork:failedtoacquirelease:node"k8s-node2"podcid

kubectlpatchnodek8s-master-p'{"spec":{"podCIDR":"10.244.0.0/12"}}'kubectlpatchnodek8s-node1-p'{"spec":{"podCIDR":"10.244.0.0/12"}}'

Unabletoconnecttotheserver:x509:certificatesignedbyunknownauthori

要素:重新初始化环境没有清算洁净

mkdir-p$HOME/.kubesudocp-i/etc/kubernetes/admin.conf$HOME/.kube/configsudochown$(id-u):$(id-g)$HOME/.kube/config

ERRORFileContent--proc-sys-net-bridge-bridge-nf-call-iptables]:

echo"1">/proc/sys/net/bridge/bridge-nf-call-iptables

error:noconfigurationhasbeenprovided,trysettingKUBERNETES_MASTERenvironmentvariable

在/etc/profile末尾参与exportKUBECONFIG=/etc/kubernetes/admin.conf参与完后口头source/etc/profile

svc不能被解析的要素

现象

pod能ping外网但是不能解析百度能ping114不能pingsvc地址

处置

对应的node上方没有开启转发(详细疑问可以先检查node上方的kube-proxylogs由于svc是经过kube-proxy散收回去的)echo1>/proc/sys/net/bridge/bridge-nf-call-iptables

Errorregisteringnetwork:failedtoacquirelease:node"master2"podcidrnotassigned

设置podip的网段,网段之所以是10.244.0.0/16,是由于前面装置flannel网络插件时,yaml文件外面的ip段也是这个,两个坚持分歧,不然或许会使得Node间ClusterIP不通。这个参数必定得指定,假设这里不设置的话前面装置flannel网络插件时会报这个失误

lyingcgroup…caused:mkdir…nospaceleftondevice或许在describepod的时刻出现cannotallocatememory

处置方法

当少量pod出现evictive状况

说明节点资源不够,清算空间

ingress失掉源地址ip为127.0.0.1疑问

假设ingress-nginx启用了enable-ssl-passthrough,就要求参与 enable-real-ip:true

forwarded-for-header:proxy_protocol 到configmap外面就可以了

etcd节点意外复原(openshift)

master节点缺点,dockerps-a|grepetcd|grep-vPOD发现etcd意外分开

检查日志

dockerlogs-fetcd...···etcdserer:openwalerror:wal:filenotfound

复原步骤

将缺点节点剥离集群,复原后参与

etcdctl2cluster-health失掉疑问节点的memberidetcdclt2memberremove$memberid将疑问节点移除----中止疑问节点上的etcd服务mkdir-pv/etc/orgin/node/pods-stoppedmv/etc/origin/node/pods/*/etc/orgin/node/pods-stoppedrm-rf/var/lib/etcd/*----更新ansible中的inventoryhost内容,设置newetcd性能[osev3:clildren]mastersetcdnodesnew_etcd----从集群中监禁疑问节点----更新etcd扩容脚本ansible-playbookplaybooks/openshift-master/openshift_node_groups.yaml----验证etcdctlclister-health

节点notready

rpcerror:code=ResourceExhausteddesc=grpc:tryingtosendmessagelargerthanmax(xxxxxxxvs.8388608)

形容

集群有个master节点NotReady。kubelet报错WarningContainerGCFailed...

WarningContainerGCFailed...rpcerror:code=ResourceExhausteddesc=grpc:tryingtosendmessagelargerthanmax(xxxxxxxvs.8388608)

这个错和上方是一个疑问。

rpcerror:code=ResourceExhausteddesc=grpc:receivedmessagelargerthanmax(xxxxxvs.4194304)

要素

超越的根源在于容器数量过多,grpc前往信息过大,从而你超越了限度,不可正确前往。

处置方法

检查GRPCBuff块大小,扩展至8MB。扩展方法参考

假设曾经是8MB,依然报错,则或许是镜像等docker资源要求清算。可以口头

dockersystemprune

为了根除此类失误,可以在节点上设置完善的GarbageCollection机制。参考

GarbageCollectiondocs.openshift.com/container-platform/3.11/admin_guide/garbage_collection.

node拉取镜像速度很快,但是起pod镜像很慢

PodsgetstuckinContainerCreatingstatewhenpullingimagetakeslong

apiserver前面经常使用的是f5的负载均战略有疑问,造成恳求所有打在了master1上、

运行缺点

不同ns之前的pod怎样访问

创立一个networkpolicy的Ingress

apiVersion:extension/v1beta1Kind:NetworkPolicymetadata:generation:name:allow-from-{ns1}-namespacenamespace:{ns2}spec:ingress:-from:-namespaceSelector:matchLabels:name:{ns1}podSelector:{}policyType:-Ingress

pod内出现nospaceleftondevice

说明耐久化存储资源无余

pod处于running域名访问404

审核routeingress能否为反常形态本地性能host能否解析反常

networkplugincnifailedtosetuppod

处置

找到调度的节点,重启sdn

k8s

kubectlgetopenshift-sdndeletepo--grace-period=0--forcesdn-xxx

不通pod经过servicehostname访问不通

经过排查为networkplicy缺少

pod不时被重建

由于ns开启可vpa造成

admission是会去手动改request值updater组件会发现request大于介绍去驱逐而后admission挂了改不了requestpod一同来updater发现它大于介绍request就会驱逐而后不时循环在驱逐

而后pod会揭示找不到cm

运行做更新,一切的yaml都在一个文件外面,或许是cm更新的慢了,而后pod会揭示找不到cm,pod重启还是会找不到cm

timeoutexpiredwaitingforvolumestoattachormountforpod

eureka的疑问:pod不存在了,容器存在,up中有ip,可以调度

pod形态terminating,强迫删除了,但是容器没有删除造成的

pod智能重启,pod名字不变,ip和创立期间变动

VPA目前驱逐pod后pod名字不会变但是ip和创立期间会变,VPA封锁后无此现象

压力测试短衔接pod负载不平衡

会话坚持必定封锁

a运行性能ssl之后跳转到了其余的地址

a运行经常使用了b运行的证书

pod存活几秒钟重启

vpa-admin-controller意外pod

service选用不通的depoy的pod

service经过label选用pod,可以在A,B的deploy区分参与一个相反的标签,svc中的selector经常使用这个相反的标签,这样就可以选用A和B的deploy创立的pod

经过router4层可以下载,经过7层下载502gataway

审核haproxy的疑问,开启haproxy的日志

ip地址抵触排查

体现为ping不通,telnet失败

arping-Iens3310.0.13.3

假设存在多个地址,则标明地址抵触

如何删除terminating的ns

现象

kubectlgetnsdemoterminating50d

检查编排内容

kubectlgetnsdemo-ojson
"spec":{"finalizers":["kubernetes"]},删除上方这段而后导入到新的jjson文件外面curl-k-H"Content-Type:application/json"-XPUT--data-binary@1.sjon

configmap中的entrypoint.sh无口头权限

在configmap上方参与相熟mode:493(十进制,八进制就是755)

configmap:name:xxxitems:-key:entrypoinyt.shpath:entrypoiny.shmode:493

buildimagenospaceleftondevice

怎样修正

修正docker启动参数vim/etc/systemd/system/multi-user.target.wants/docker.service在exec参数前面加上--graph=/xx/xxx/xxsystemctldaemon-reloadsystemctlrestartdocker修正daemon.jsono{"data-root":"/xxx/xxx"}

theserverdoesn’thavearesourcetype‘xxx’

~/.kube客户端认证文件失效或许损坏,从其余节点的root用户拷一份上来即可

tcprouter不通,不可经过tcp衔接到服务

登陆到router部署的节点

netstat-tnlp检查端口能否反常监听

kubectl-ndefaultrouterxxxrshgrep-i"xxxx"-r./

检查tcp-router能否有显著失误日志

kubectl-ndefautlogs-frouterxxx--tail=10

检查端口范围

iptables-nLINPUT

怎样指定用户id启动运行runasuser

创立sakubectlcreatesa-nxxxxxx参与sa到对应的scckubectladmpolicyadd-scc-to-useranyuid-nxx-zxxx修正部署文件serviceAccount:xxxserviceAccountName:xxxspec.template.spec.container[]securityContext:runAsuser:xxx

node可以解析,pod不能解析

处置Kubernetes中Pod不可反常域名解析疑问剖析与IPVSparseIPError疑问系统环境:CoreDNS版本:1.6.7Docker版本:19.03.8Kubernetes版本:1.18.1操作系统版本:7.8CentOS内核版本:3.10.0-1062参考地址:KubernetesGithubCentOS更新内核版本Kubernetes官网文档-ServicesKubernetes官网文档-调试DNS服务Kubernetes官网文档-自定义DNS服务Issues"ipvsdonotsyncendpointerror:parseIPError"疑问剖析比拟长,剖析的疑心人生...一、疑问形容最近将Kubernetes更新到1.18.1版本,不过更新完后,检查上班节点的局部Pod不可启动,检查信息全是connetiontimeout的疑问,一看衔接超时的地址大局部是以域名形式衔接集群外部地址(ClusterIP),少局部是以域名形式衔接集群外部地址,经过IP启动远程衔接的运行倒是没有疑问(例如,运行经过IP衔接),由此判别,初步疑心很或许是DNS出现了疑问,起初缓缓发现kube-proxy中的失误,再定位到IPVSparseIPError失误,再到处置疑问。上方是剖析及姐疑问的环节。二、部署DNS调试工具为了探针能否为DNS疑问,这里要求提早部署用于测试DNS疑问的dnsutils镜像,该镜像中蕴含了用于测试DNS疑问的工具包,十分利于咱们剖析与发现疑问。接上去,咱们将在Kubernetes中部署这个工具镜像。1、创立DNS工具Pod部署文件创立用于部署的Deployment资源文件ndsutils.yaml:ndsutils.yamlapiVersion:v1kind:Podmetadata:name:dnsutilsspec:containers:-name:dnsutilsimage:mydlqclub/dnsutils:1.3imagePullPolicy:IfNotPresentcommand:["sleep","3600"]2、经过Kubectl工具部署NDS工具镜像经过Kubectl工具,将对上方DNS工具镜像部署到Kubernetes中:-n:指定运行部署的Namespace空间。$kubectlcreate-fndsutils.yaml-nkube-system三、疑问剖析1、进入DNS工具Pod的命令行上方DNS工具曾经部署成功,咱们可也经过Kubectl工具进入Pod命令行,而后,经常使用外面的一些工具启动疑问剖析,命令如下:exec:让指定Pod容器口头某些命令。-i:将控制台内容传入到容器。-t:进入容器的tty经常使用bash命令行。-n:指定上方部署DNSPod所在的Namespace。$kubectlexec-itdnsutils/bin/sh-nkube-system2、经过Ping和Nsloopup命令测试进入容器sh命令行界面后,先经常使用ping命令来区分探测观察能否能够ping通集群外部和集群外部的地址,观察到的信息如下:##Ping集群外部,例如这里ping一下百度$pingwww.baidu.comping:badaddress'www.baidu.com'##Ping集群外部kube-apiserver的Service地址$pingkubernetes.defaultping:badaddress'kubernetes.default'##经常使用nslookup命令查问域名信息$nslookupkubernetes.default;;connectiontimedout;noserverscouldbereached##间接Ping集群外部kube-apiserver的IP地址$ping10.96.0.1PING10.96.0.1(10.96.0.1):56>podping不通node

环境说明

pod--->router--->svc---pod

namesapce1的pod访问不了router访问拒绝

要素:apiserver重启造成sdn重启,防火墙战略没有失效,重启防火墙后处置


基于Kubernetes的持续部署方案

文章转载自Docker

方案概述

本技术方案为基于Kubernetes为核心的持续部署(下文简称CD)方案,可以满足开发方的程序级日志查看分析,运维方的快速扩容与日常运维分析,并且可以保证用户的服务体验。并且整套放在可以在资源利用率上进一步提升,在不降低服务可靠性的前提下降低资源使用成本。

使用场景分析

本方案适用于以Tomcat为容器的JavaWeb项目的持续部署过程,在Kubernetes方案中,所有的Node节点均采用统一配置,根据业务环境的需求进行节点数量的控制。

技术架构与选型

Kubernetes集群部署模式:Stacked etcd topology

Kubernetes的安装使用kubeadm安装为高可用集群,并选用Stacked etcd topology 模式。

详情参考。

Kubernetes生态技术选型:网络层面选型Weave

容器网络解决方案。Weave创建的虚拟网络可以将部署在多个主机上的容器连接起来。对容器来说,Weave就像一个巨大的以太网交换机,所有容器都被接入这个交换机,容器可以直接通信,无需 NAT 和端口映射。

原理详解:Kubernetes生态技术选型:对外服务选型NodePort

Kubernetes目前支持NodePort、LoadBanlace、Ingress三种对外提供服务的模式,其中LoadBanlace需要云平台的支持,阿里云提供了解决方案,但腾讯云未找到,Ingress技术为新出技术。整体评估采用NodePort方式更为灵活,每个服务一个唯一的对外IP地址,并且使用Nginx进行负载均衡(采用Nginx主要为日志分析)。

介绍与使用方法:。

持续部署过程

各组件业务配置

Kubernetes业务配置

命名空间

在业务上,Kubernetes默认配置两套Namespace,分别为Master存放正式环境,Develop配置测试环境。

对外端口

正式环境Web端口以开始,测试环境以开始,且一一对应。

Master数据目录

K8s-Master下的data目录下为k8s-cd-config, k8s-cd-config目录存放各业务的yaml配置,二级目录为域名,三级目录划分Master(正式),Develop(测试),目录下以 版本号-构建 命名文件,时间最后一个即为当前线上的使用配置文件,为了运维方便,在二级目录同级内,生成一个软链连接到最新的正式与测试配置文件。注意,k8s-cd-config仅在其中一台Master中存在。

Node数据目录

节点下的/data一级目录下分Filebeat、Dockerlibs、Nodelogs,其中Dockerlibs存放Docker相关数据,Nodelogs目录通过volume的方式挂载入Kubernetes的Pod, Nodelogs下分Develop与Master目录,区分正式环境与测试环境,每个Master与Develop下分为accesslogs、devlogs、tomcatlogs分别存放访问日志,开发部日志,Tomcat日志,日志目录下为项目(域名),域名下为Pod名称目录。

注意事项 : 节点加入集群后,一定要下载手工下载kubernetes-dashboard-amd64镜像,防止dashboard所在节点挂掉以后dashboard无法在其他节点启动。

Harbor业务配置

业务分组

Harbor重定义其Registry的存储路径直接使用docker-compose安装。template 存放基础进项,各域名分组存放业务镜像。

镜像命名

分组下镜像以站点域名:版本号-类型-CDGITLAB为名称,并基于版本号确定不同的站点版本。

数据目录

Harbor数据目录统一存放在/data下。

备份策略

Harbor默认不设置备份,对于业务镜像无需进行备份,每次进行构建即可,对于模板类镜像,在Jenkins机器上均可以找到,若Harbor出现问题,则直接重建,并将Jenkins上的模板镜像进行重新push。

注意:为了业务的稳定性,Harbor由独立的服务运行(基于Docker),并不运行在Kubernetes内。

Jenkins业务配置

数据目录

Jenkins下的data目录分为dockerlibs、thinbackups、gitlab-files 、jks-cd-config。

Dockerlibs存放Docker相关文件,thinbackups存放每日的Jenkins备份,gitlab-files存放构建GitLab的文件(运维可以在此操作pull,push),jks-cd-config为jks构建目录。

Jenkins机使用/data/jks-cd-config目录存放构建内容,二级目录为域名,三级目录为版本号(以开发部版本号为准),三级目录下存放,四级目录为构建ID_GITID,目录下存放构建的原始数据。

节点每天进行images清理工作。

业务分组

Jenkins的分组分为template与各domain,template存放模板,domain以域名的形式存放正式项目:

新项目由运维手工创建,后续的秩序构建过程由开发部调用API完成。

构建参数

Jenkins构建时,需要传递三参数,1:程序版本号,2:类型:apply与delete,3:正式环境还是测试环境,正式环境为Master,测试环境为Develop,对应Kubernetes的Namespace。

此部分功能后期将通过开发部的构建凭条调用JenkinsAPI实现。

JenkinsAPI

APIDoc:Token:备份策略

Jenins安装ThinBackup插件,配置每小时进行一次全局备份,且最多保留10份,备份后数据传至异地。

注意:为了业务的稳定性,Jenkins由独立的服务运行,并不运行在Kubernetes内。

GitLab业务配置

业务分组

CD GitLab项目下分两个组template与各domain,template存放模板文件。例如:

Git分支

default下以域名划分项目,每个项目划分Master与Develop两个分支,分别存放正式环境与测试环境CD文件。

CD文件树

备份策略

GitLab使用gitlab-rake gitlab:backup:create进行每日定期备份,并传送至异地。

EFK与日志管理

Elasticsearch

ES数据通过索引仅保留近10天的数据,每日通过脚本方式进行数据删除。ES的数据保存在/data/elasticsearch目录下。

在每个Node节点启动一个Filebeat进程,用于日志的采集工作,filebeat分别监控:

其中,tomcatlogs日志需要进行特殊处理,进行多行合并,数据写入ES时,使用processors. Dissect进行目录名称截取,并使用域名作为ES的索引使用。

截取gy. wtype ( master或develop) , ltype(accesslogs 、tomcatlogs、devlogs),domain()。

Kibana目前我们仅使用其discover节点,用于日志数据的查询,在配置方面。

Kibana配置使用“域名-*”方式进行配置,每次新增域名,需要在此进行手工配置。

Kibana使用discover查看时,默认展示一个域名下所有的日志,可以通过筛选选择查看测试环境还是正式环境,或者通过哪种日志类型。

容器资源监控

容器资源使用WeaveScope进行资源消耗监控。

福利

扫描添加我微信,备注“ 姓名+公司职位 ”,加入【 云计算学习交流群 】,和志同道合的朋友们共同打卡学习!

推荐阅读:

喜欢就点击“好看”吧

关于k8s运维的面试问题

最近正在找工作,面试了很多运维相关的岗位,基本都要求有k8s经验,虽然目前k8s基本趋于成熟化,但对于传统运维工作人员和刚毕业的学生来讲,这确实太过于复杂;但在面试中,面试官往往最喜欢问就是k8s相关技术问题,然而因为各种原因,我有近3年的运维工作空档期,于是乎我掌握的技术都太过时了;在面试碰壁中总结了关于k8s的面试问题,所以在这里提前为1000万要毕业的大学生做点力所能及的。 从业有11年多,也为公司招过不少人。 现在的面试官与年龄无关,在选人上太注重这个人的面试成绩或者这个人的匹配度。 其实往往忽略了人本身,技术是靠人做出来的,人本身才是最重要的。 你有再光鲜华丽的履历,有再多的荣誉都不能改变本性,江山易改本性难移。 技术差一点这个没什么,可以给时间,可以培养,但是态度、人品不行,再好的技术都没用,只会是团队中的绊脚石。 在面试时,多用心观察对方的行为,思维,态度。 1.人品 2.态度 3.技术思维 1.核心组件或者说是基础组件,需要弄清有哪些,都是有什么作用。 2.会挑一两个问其如何工作,如何实现。 核心组件:etcd、api、controller、scheduler、docker 核心组件:kubelet、docker、kube-proxy

免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。

标签: k8s

“Kubernetes-部署和保养常见疑问汇总 (kubernetes与docker的关系)” 的相关文章

疾速入门-k8s-实战-kubernetes-集群治理-五分钟 (疾速系列)

疾速入门-k8s-实战-kubernetes-集群治理-五分钟 (疾速系列)

当咱们在消费环境颁布运行时,必定要思索到以后系统还有用户正在经常使用的状况,所以尽量要求做到不停机发版。 所以在颁布环节中通常上之前的v1版本依然存在,必定得期待v2版本启动成功后再删除历史...