参考了 https://blog.csdn.net/nklinsirui/article/details/80855415 最近在调研 kubeneter ,准备把线上的服务器架构再调整下,然后模拟各种极端环境,就遇到了重启后启来不 kubectl get pods --all-namespaces 显示: The connection to the server was refused - did you specify the right host or port? [root@k8s-no

Pod 的重启策略有 3 种,默认值为 Always. Always : 容器失效时,kubelet 自动重启该容器: OnFailure : 容器终止运行且退出码不为0时重启: Never : 不论状态为何, kubelet 都不重启该容器. 失败的容器由 kubelet 以五分钟为上限的指数退避延迟(10秒,20秒,40秒…)重新启动,并在成功执行十分钟后重置. 在yaml编排文件中restartPolicy: OnFailure要和container并排. [root@k8s-master

原文的帖子无法访问,我只能粘贴内容 近期将之前的一个用Kubernetes 1.3.7的环境更换为最新发布的用kubeadm安装的Kubernetes 1.6.4 Dashboard无法访问的问题>一文中,我们通过把用户admin bind到cluster-admin这个clusterrole角色上使得dashboard得以正常访问.但访问几次后,我发现了一个问题:那就是用safari访问dashboard时,浏览器可以正常弹出鉴权对话框,让我输入用户名和密码:但用chrome访问时,总是无法弹

Background kubernetes是master-slave结构,master node是集群的大脑, 当master node发生故障时整个集群都"out of control".master node中最重要的当属apiserver组件, 它负责处理所有请求, 并持久化状态到etcd. 一般我们会部署多份apiserver实现高可用.官方建议在多个apiserver前面部署一个LB进行负载均衡,当其中一台apiserver发生故障之后,LB 自动将流量切换到其他实例上面.这

一.问题现象和原因 Kubernetes 日志错误 当 Kubernetes 集群日志中出现 certificate has expired or is not yet valid 错误信息时,表明证书过期 证书过期原因 服务器时间不对,导致证书过期 确实证书过期了 证书过期,很多同学会很疑惑,我证书明明签署10年有效期或者更久,怎么刚1年就过期了,下面就来解惑. Kubernetes 集群证书 集群分为两种证书:一.用于集群 Master.Etcd等通信的证书. 二.用于集群 Kubelet 

pod声明周期(状态):pending , running, succeeded, failed, unknown 挂起(Pending):Pod 已被 Kubernetes 系统接受,但有一个或者多个容器镜像尚未创建.等待时间包括调度 Pod 的时间和通过网络下载镜像的时间,这可能需要花点时间. 运行中(Running):该 Pod 已经绑定到了一个节点上,Pod 中所有的容器都已被创建.至少有一个容器正在运行,或者正处于启动或重启状态. 成功(Succeeded):Pod 中的所有容器都被成

Pod 在整个生命周期中被系统定义为各种状态,熟悉 Pod 的各种状态对于理解如何设置 Pod 的调度策略.重启策略是很有必要的. Pod 的状态 状态值 描述 Pending API Server 已经创建该 Pod,但在 Pod 内还有一个或多个容器的镜像没有创建,包括正在下载镜像的过程 Running Pod 内所有容器均已创建,且至少有一个容器处于运行状态.正在启动状态或正在重启状态 Succeeded Pod 内所有容器均成功执行后退出,且不会再重启 Failed Pod 内所有容器均

容器中的磁盘文件生命周期比较短暂,在一些比较复杂的容器应用中会产生一些问题.一.容器crash后,kubelet会重启该容器,但这些文件会丢失掉.二.pod中的多个容器经常需要共享文件.因此,Kubernetes的Volume应然而生,用于解决这些问题. 背景 在Docker中,也有volumes这个概念,volume只是磁盘上一个简单的目录,或者其他容器中的volume.生命周期也不受管理,并且直到最近他们都是基于本地后端存储的.Docker现在也提供了volume driver,但是现在来说

Linux 中有 cron 程序定时执行任务,Kubernetes 的 CronJob 提供了类似的功能,可以定时执行 Job.CronJob 配置文件示例如下: ① batch/v2alpha1 是当前 CronJob 的 apiVersion. ② 指明当前资源的类型为 CronJob. ③ schedule 指定什么时候运行 Job,其格式与 Linux cron 一致.这里 */1 * * * * 的含义是每一分钟启动一次. ④ jobTemplate 定义 Job 的模板,格式与前面

本文收录在容器技术学习系列文章总目录 1.认识存储卷 1.1 背景 默认情况下容器中的磁盘文件是非持久化的,容器中的磁盘的生命周期是短暂的,这就带来了一系列的问题:第一,当一个容器损坏之后,kubelet 会重启这个容器,但是文件会丢失-这个容器会是一个全新的状态:第二,当很多容器在同一Pod中运行的时候,很多时候需要数据文件的共享.Kubernete Volume解决了这个问题. 1.2 介绍 Docker有一个Volumes的概念,虽然这个Volume有点宽松和管理性比较小.在Docker中

存储卷概述 容器磁盘上的文件的生命周期是短暂的,这就使得在容器中运行重要应用时会出现一些问题.首先,当容器崩溃时,kubelet 会重启它,但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动.其次,在 Pod 中同时运行多个容器时,这些容器之间通常需要共享文件.Kubernetes 中的 Volume 抽象就很好的解决了这些问题.在原docker环境中也有存储卷的概念,但docker环境的存储卷调度在宿主机上的目录,当docker重新创建的时候存储卷还会挂载统一宿主机上,但我们

文章参考:https://www.kubernetes.org.cn 简介 Kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效(powerful),Kubernetes提供了应用部署,规划,更新,维护的一种机制. Kubernetes一个核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着(比如用户想让apache一直运行,用户不需要关心怎么去做,Kubernetes会自动去监控,然后去重

第一章.前言 默认情况下容器的数据都是非持久化的, 在容器消亡以后数据也跟着丢失, 所以 Docker 提供了 Volume 机制以便将数据持久化存储. 类似的, Kubernetes 提供了更强大的 Volume 机制和丰富的插件, 解决了容器数据持久化和容器间共享数据的问题. 与 Docker 不同, Kubernetes Volume 的生命周期与 Pod 绑定容器挂掉后 Kubelet 再次重启容器时, Volume 的数据依然还在而 Pod 删除时, Volume 才会清理. 数据是否

CountingStars_ 关注 2018.08.12 09:06* 字数 464 阅读 88评论 0喜欢 0 简介 使用kubeadm配置多master节点,实现高可用. 安装 实验环境说明 实验架构图 lab1: etcd master haproxy keepalived 11.11.11.111 lab2: etcd master haproxy keepalived 11.11.11.112 lab3: etcd master haproxy keepalived 11.11.11.

Kubernetes 系统提供了三种认证方式:CA 认证.Token 认证 和 Base 认证.安全功能是一把双刃剑,它保护系统不被攻击,但是也带来额外的性能损耗.集群内的各组件访问 API Server 时,由于它们与 API Server 同时处于同一局域网内,所以建议用非安全的方式访问 API Server 效率更高. 接下来对集群的双向认证配置和简单认证配置过程进行详细说明. 双向认证配置 双向认证方式是最为严格和安全的集群安全配置方式,主要配置流程如下: 生成根证书.API Serve

=============================================== 2018/3/22_第2次修改                       ccb_warlock 更新说明: 2018/3/22:修改了6.7中k8s-dashboard中url错误的问题: =============================================== 为了让产品在迎来业务量爆发式增长前完成应对措施,在浏览无数的资料后,决定将服务逐渐进行容器化,最终能达到容器集群的

Kubernetes集群中垃圾回收(Garbage Collection)机制由kubelet完成.kubelet定期清理不再使用的容器和镜像,每分钟进行一次容器的GC操作,每五分钟进行一次镜像的GC操作. 容器(Container)的GC设置 能够被清理的容器只能是仅由kubelet管理的容器.在kubelet节点上通过docker run创建的容器不会被kubelet进行GC清理操作. kubelet以下3个参数用于设置容器GC的条件: --minimum-container-ttl-dur

目录 Kubenetes资源 常用资源对象 标签labels 创建资源的方式 Pod pods.spec.containers 必须 nodeSelector <map [string]string> nodeName<map [string]string> annotations restartPolicy hostNetwork pod的生命周期 健康监测 lifecycle env环境变量获取 pod 案例 Pod控制器 deployment DaemSet Service

前言 本篇部署教程将讲述k8s集群的节点(master和工作节点)部署,请先按照上一篇教程完成节点的准备.本篇教程中的操作全部使用脚本完成,并且对于某些情况(比如镜像拉取问题)还提供了多种解决方案.不过基于部署环境和k8s的复杂性,我们需要对k8s集群部署过程中的一些步骤都有所了解,尤其是“kubeadm init”命令. 目录 主节点部署  Kubeadm以及相关工具包的安装 批量拉取k8s相关镜像 使用“kubeadm init”启动k8s主节点 启动k8s主节点 kubectl认证 安装f

kubernetes社区非常活跃,每季度都会发布一个release.但是线上集群业务可用性要求较高,场景复杂,任何微小的变更都需要非常小心,此时跟随社区版本进行升级略显吃力.但是为了能够使用到最新的一些feature我们必须不定期进行一些升级操作,在经历了一次线上集群的升级操作,踩完一些坑之后,分享一些收获与感悟.原来的集群版本是1.10,为了提高GPU集群的资源利用率,需要在调度器层面支持一些抢占调度等新特性,所以升级到1.14,此次升级的集群规模不是特别大,但是有一些在线任务,还是需要慎重操

一 Pod定义详解 1.1 完整Pod定义文件 apiVersion: v1 #必选,版本号,例如v1,版本号必须可以用 kubectl api-versions 查询到 kind: Pod #必选,Pod metadata: #必选,元数据 name: string #必选,Pod名称,需符合RFC 1035规范 namespace: string #必选,Pod所属的命名空间,默认为"default" labels: #自定义标签 - name: string #自定义标签名字 a