一直“上一步”,回到集群基本信息设置,别勾选可用区c的交换机,之后再继续往后走。
请直接在答疑群反馈,找hangyu。
1)Pod网段要求,以下网段及其子网:10.0.0.0/8,172.16-31.0.0/12-16,192.168.0.0/16。
2)Service网段要求,以下网段及其子网 10.0.0.0/16-24,172.16-31.0.0/16-24,192.168.0.0/16-24。
3)不能与 VPC 及 VPC 内已有 Kubernetes 集群使用的网段重。
首先找到集群使用的VPC的网段,保证Pod以及Service的网段不和VPC网段冲突。
比如VPC网段为192.****,那完全可以设置Pod的Service的网段以172开头的,网页上有提示设置的网段规则,比如分别设置为172.20.0.0/16,172.21.0.0/20。
如果之前创建过集群,那么查看这个集群已经设置好的Pod和Service的网段,然后相应的增加就好,比如分别设置
172.22.0.0/16,172.23.0.0/20。
另比如,VPC的网段为172.16.0.0/12,Pod网段和Service网段可以分别设置为"10.1.0.0/16"和"10.2.0.0/16",因为这两个网段均属于10.0.0.0/8的子网段,且不和vpc网段冲突,所以符合要求
集群初始化后异步添加节点失败了,具体原因可见集群日志:集群列表-查看日志;
根据具体日志找原因,先在此文档找;
手动添加,集群管理-节点列表-添加已有节点;
首先,VPC必须有出公网能力才能创建集群,请参考 NAT网关解惑。
原因:找不到交换机粒度的SNAT条目,说明创建集群第一步中选择的交换机中有没有配置SNAT的。
首先,VPC必须有出公网能力才能创建集群,请参考 NAT网关解惑。
原因:vpc无法出公网,没有配置SNAT。解决方法:
1)手动配置SNAT,参考 创建集群前的网络建设,然后再提交创建集群;
2)自动配置,创建集群页面勾选“配置SNAT”,勾选提交后会创建一个后付费NAT网关,一个按流量后付费EIP。
集群初始化失败,具体原因可见集群日志:集群列表-查看日志;
例如,如下日志说明账户欠费了,导致集群创建失败。
1)会创建内网SLB一个,免费。集群api server使用,请不要删除,也不要更改监听配置!!
2.1)创建集群时如果勾选“配置SNAT”,且VPC网络内不存在NAT网关,则会创建如下资源:
一个后付费的NAT网;一个后付费的弹性公网IP;
2.2)创建集群时不勾选“配置SNAT”
如果VPC本身没有手动配置过SNAT,则创建集群会提示失败;
如果VPC本身已经有了SNAT,则可以复用原来的,集群可以成功创建。
3)对于之前(2020.1.16之前)创建的集群,还会有第二个EIP。
这个是用于集群api server的公网ip,理论上无流量费用,可以删除。请答疑群联系杭羽or明涵。
注,2020.1.16之前创建的集群才有,之后创建的集群不会有。
检查淘宝账号是否已经实名认证:https://member1.taobao.com/member/fresh/account_management.htm?spm=0.0.0.0.haYidt。
资源视图-配额管理-负载均衡,“用户可保有的slb实例个数”申请更大的配额,申请后由阿里云自动审核。
EIP实例数量达到上限,需要先申请下EIP数量的更大配额。类似上面问题10,进入资源视图-配额管理-弹性公网EIP,申请EIP数量上限,申请后由阿里云自动审核。
通常原因:集群创建时自动创建的资源,如果被其他云产品(集群以外的)所依赖,删除时资源无法释放,会导致集群无法删除。一个示例:集群日志显示,集群所创建的安全组中加入的其他ECS,导致安全组无法删除。
cf8c0a3e21c354580b887640c454d20be | Failed to delete cluster with Aliyun API Error: RequestId: 5269F70A-8240-4081-A280-FCBB54842608 Status Code: 403 Code: DependencyViolation Message: There is still instance(s) in the specified security group.
解决方法:
1)清理相关的云资源依赖,再次删除集群;
2)删除集群时勾选有依赖关系的云资源,集群删除时会跳过该云资源。
集群上有运行着的弹性容器ECI实例,需要先对应用做下线或者缩容操作(二选一),才能进行集群删除。
1)应用缩容:进入具体环境-实例管理-手动扩缩容,调整后配置实例数设置为0。
2)应用下线:环境管理-(更多)下线。
所选ECS已经加入了5个安全组,阿里云限制每台ECS最多加入5个安全组,加入集群需要加入另一个安全组。
解决办法,将ECS退出其他安全组,保证加入的安全组数量<=4。
ECS控制台,安全组配置,查看ECS所在的安全组。
特别地,如果是下列两种名字开头的安全组,可以直接退出该安全组。
背景:节点添加到集群,需要加入集群所在安全组(集群创建时新建,可以在运维中心集群详情里查看到)。
集群安全组属于普通安全组,如果ECS已经加入了企业安全组,就无法添加到集群了。
解决方案:新购买ECS机器,购买时选择一个普通安全组,之后再添加集群。
VPC路由表超限,VPC控制台-配额管理,申请一下该VPC下的路由表quota,申请会自动审核。如果审核有问题,提提交阿里云工单咨询。
找到创建集群使用的VPC,提交阿里云工单,申请一下该VPC下的EIP quota。
首先,确认下ECS是否和集群的VPC属于同一个。
其次,确认下ECS是否已经关联到聚石塔的应用,关联了应用的机器原则上不能添加进集群(机器会被重置)。
最后,确认ECS实例的状态,是否过期,是否为running状态。
PS,添加节点时没有列出想要的实例,一般是因为
1)ECS与集群不在同一个VPC;
2)ECS已经添加到其他集群。
3)ECS过期 ;
4)ECS关联了应用(如果关联了需要先取消关联)。
可以手动校验一下:
1)ECS关机状态或者已经过期、或者已经添加过集群中了(正在异步初始化 所以无法添加,具体可看集群日志,这种情况稍等一下就好)
2)集群失联导致,检查集群创建时自动生成的内网SLB是否是已停止或者已经被删除
3)运维中心 集群列表,查看集群日志
如果SLB停止了,请打开运行;
如果SLB已经被删除了,那只能新建集群了
直接升级就好,集群内立即生效,不需要重新添加到集群;
集群-节点列表,信息展示的ECS规格有延迟,一般是凌晨同步,不影响集群使用。
没有严格规定,可以只有一台机器,但是建议最少两台,保证可用性。
每个节点都有一部分存储空间叫做临时存储空间,这部分空间被集群管理和定时回收。临时存储空间的意义是,这部分存储空间内的数据不被保证持久性,通常存储的是一些日志,镜像等内容。临时存储空间包括以下的内容:
1)Docker或者K8S所占用的系统空间,用于存放Docker日志,Kubelet日志,或者是其他系统挂载空间(这部分空间通常不会占用大量宿主机磁盘空间)。默认的存储目录包括但不限于:/var/log,/var/lib/kubelet
2)容器(POD)所使用的空映射目录(emptyDir)。通常一定不要再emptyDir中存储过大的内容,或者是重要不可丢失数据。否则可能引发严重的磁盘占用问题和数据丢失问题。
3)容器运行时的所有未挂载的数据(runtime imagefs)。比如tomcat直接在容器内不停打日志,而日志目录又没有通过宿主机目录挂载或者NAS挂载出去,导致容器运行时可写目录持续增大。这部分数据在宿主机的docker数据目录下,默认是/var/lib/docker
4)容器镜像所占用的空间。
1)计算节点,用于部署windows容器,例如.net asp等应用,这个是一定要添加的,不然没法起容器。
2)组件节点,用于部署集群底层组件,例如coredns等(底层系统是linux)。
对于linux集群来说,添加的节点都是计算节点,因为linux集群上的系统组件可以与应用容器共同存在于ECS节点上。不管是linux集群还是windows集群,系统组件占用的资源量基本是一样的,总占用1.5核 1.5G左右,所以对于windows集群来说,可以理解为将系统组件和应用容器分开了,一个组件节点用于放系统组件,其他的计算节点用于放业务容器。添加上的计算节点几乎全部用于部署应用容器。
是否需要给windows集群添加组件节点?
需要,系统组件提供了基本的底层能力,比如coredns,没有这个的话应用容器中无法解析域名,无法访问redis rds等;比如monitor controller,默认集成了CMS云监控,可以监控容器指标。另外,组件节点没有规格要求,一个节点就基本足够,建议是2核2G。
集群水位:如果windows集群没有组件节点(没有metric-server),则无法统计集群的水位。
1)移除节点会涉及Pod迁移,可能会影响业务,请在业务低峰期操作。
2)操作过程中可能存在非预期风险,请提前做好相关的数据备份。
3)操作过程中,后台会把当前节点设置为不可调度状态。
4)移除节点为异步操作,请稍后刷新页面查看。
勾选“自动排空节点”后,会先将该节点上POD容器排空(即驱逐出当前节点,调度到其他节点)。
1)选择设置为不可调度,节点状态变为不可调度。即在后续进行应用部署时,Pod不会再调度到该节点。
2)选择设置为可调度,节点状态变为可调度。
3)选择排空节点(同时设置为不可调度),节点状态变为不可调度,同时会将节点上已经存在的Pod进行(排空)驱逐,pod会被调度到其他节点进行重建。注意:节点上由守护进程集DaemonSet控制的Pod不会被排空。
建议使用如下快恢流程恢复节点到Ready(可用)状态:
1)先登录异常节点重启kubelet,然后查看是否恢复可用。
//重启节点上的kubelet systemctl restart kubelet
如果恢复,则问题解决。后续如果怀疑该节点ECS异常,可以排空(节点维护)将Pod迁移到其他节点避免再次发生不可用影响业务,后续针对该ECS定位问题。
2)如果节点由于负载太大无法(系统平均负载监控会很大)登录并重启kubelet,则需要重启ECS。不要直接移除节点,这样子会较大程度影响该节点上的业务。注:为了避免影响本节点上已经部署的容器,重启前可以对ECS进行排空操作,排空的话,需要保证其他ECS节点上有富余资源,否则排空后容器也无法调度到其他机器。
3)如果步骤1中重启kubelet没有效果,节点依然不可用,那么需要强制重启ECS节点。通常该操作后可以恢复。 不可用的原因包括负载过高等因素。
4)避免节点不可用的建议: 保持节点和集群的合理水位,避免节点超卖严重。高负载情况会让kubelet得不到同步状态的机会。即便有部分节点NotReady,也可以使Pod驱逐、排水到其他节点。 部署npd,node export等监控组件,npd可以发现PID、磁盘空间不足等异常;node export可以较好发现NodeNotReady的异常。