集群疑问

系统

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


 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