Kubernetes: Killing container with id docker://xxxx: Need to kill Pod问题

当前Kubernetes版本 v1.9.7,当delete pod失败时,使用kubectl describe后发现这个pod有以下events信息:

这个问题是Kubernetes偶发的BUG,使用以下命令强制删除:

执行时会提示风险:

 

 

使用kubernetes PodPreset给Pod自动注入信息

参考官方介绍:

https://kubernetes.io/docs/concepts/workloads/pods/podpreset/

https://kubernetes.io/docs/tasks/inject-data-application/podpreset/

激活Pod Preset

Pod Preset目前还是alpha阶段,默认是没有激活的,所以需要通过以下步骤激活:

以阿里云的Kubernetes服务为例,阿里云的Kubernetes服务的master组件(API Server, Scheduler, Controller)都是通过Static Pod的方式用Kubelet启动,所以需要更改对应的yaml来激活Pod Preset:

编辑 /etc/kubernetes/manifests/kube-apiserver.yaml

  • 在  -runtime-config 增加  settings.k8s.io/v1alpha1=true
  • 在  --admission-control 增加  - PodPreset

保存后kubelet会自动重启 kube-apiserver组件,我们需要同时更改3台机器的master才可以。

Kubernetes滚动更新介绍及使用

我们 k8s集群使用的是1.7.7版本的,该版本中官方已经推荐使用 Deployment代替 Replication Controller(rc)了, Deployment继承了rc的全部功能外,还可以查看升级详细进度和状态,当升级出现问题的时候,可以使用回滚操作回滚到指定的版本,每一次对Deployment的操作,都会保存下来,变能方便的进行回滚操作了,另外对于每一次升级都可以随时暂停和启动,拥有多种升级方案: Recreate删除现在的 Pod,重新创建; RollingUpdate滚动升级,逐步替换现有 Pod,对于生产环境的服务升级,显然这是一种最好的方式。 Continue reading "Kubernetes滚动更新介绍及使用"

Kubernetes通过ConfigMap构建“配置管理中心”

我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等。而我们的一个应用程序从写第一行代码开始,要经历开发环境、测试环境、预发布环境只到最终的线上环境。而每一个环境都要定义其独立的各种配置。如果我们不能很好的管理这些配置文件,你的运维工作将顿时变的无比的繁琐。为此业内的一些大公司专门开发了自己的一套配置管理中心,如360的Qcon,百度的disconf等。kubernetes也提供了自己的一套方案,即ConfigMap。kubernetes通过ConfigMap来实现对容器中应用的配置管理。 Continue reading "Kubernetes通过ConfigMap构建“配置管理中心”"

Kubernetes的三种外部访问方式:NodePort、LoadBalancer和Ingress

ClusterIP

官方文档:https://kubernetes.io/docs/concepts/services-networking/service/

ClusterIP 服务是 Kubernetes 的默认服务。它给你一个集群内的服务,集群内的其它应用都可以访问该服务。集群外部无法访问它。

ClusterIP 服务的 YAML 文件类似如下:

如果 从Internet 没法访问 ClusterIP 服务,那么我们为什么要讨论它呢?那是因为我们可以通过 Kubernetes 的 proxy 模式来访问该服务!

启动 Kubernetes proxy 模式:

这样你可以通过Kubernetes API,使用如下模式来访问这个服务:

要访问我们上面定义的服务,你可以使用如下地址:

何时使用这种方式?

有一些场景下,你得使用 Kubernetes 的 proxy 模式来访问你的服务:

  • 由于某些原因,你需要调试你的服务,或者需要直接通过笔记本电脑去访问它们。
  • 容许内部通信,展示内部仪表盘等。

这种方式要求我们运行 kubectl 作为一个未认证的用户,因此我们不能用这种方式把服务暴露到 internet 或者在生产环境使用。 Continue reading "Kubernetes的三种外部访问方式:NodePort、LoadBalancer和Ingress"

在kubernets中不同命名空间的服务相互访问

涉及到的是Pod和Service之间的相互访问,主要格式如下:

详细请参考官方文档:https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/

Continue reading "在kubernets中不同命名空间的服务相互访问"

Kubernetes调度之亲和性和反亲和性

背景

Kubernetes中的调度策略可以大致分为两种,一种是全局的调度策略,要在启动调度器时配置,包括kubernetes调度器自带的各种predicates和priorities算法,具体可以参看文章《Kubernetes调度详解》;另一种是运行时调度策略,包括nodeAffinity(主机亲和性),podAffinity(POD亲和性)以及podAntiAffinity(POD反亲和性)。

nodeAffinity 主要解决POD要部署在哪些主机,以及POD不能部署在哪些主机上的问题,处理的是POD和主机之间的关系。

podAffinity 主要解决POD可以和哪些POD部署在同一个拓扑域中的问题(拓扑域用主机标签实现,可以是单个主机,也可以是多个主机组成的cluster、zone等。),podAntiAffinity主要解决POD不能和哪些POD部署在同一个拓扑域中的问题。它们处理的是Kubernetes集群内部POD和POD之间的关系。

三种亲和性和反亲和性策略的比较如下表所示:

策略名称 匹配目标 支持的操作符 支持拓扑域 设计目标
nodeAffinity 主机标签 In,NotIn,Exists,DoesNotExist,Gt,Lt 不支持 决定Pod可以部署在哪些主机上
podAffinity Pod标签 In,NotIn,Exists,DoesNotExist 支持 决定Pod可以和哪些Pod部署在同一拓扑域
PodAntiAffinity Pod标签 In,NotIn,Exists,DoesNotExist 支持 决定Pod不可以和哪些Pod部署在同一拓扑域

本文主要介绍如何使用亲和性和反亲和性做资源调度。 Continue reading "Kubernetes调度之亲和性和反亲和性"

kubectl 命令自动补全

在k8s 1.3版本之前,设置kubectl命令自动补全是通过以下的方式:

但是在k8s 1.3版本,源码contrib目录中已经没有了completions目录,无法再使用以上方式添加自动补全功能。

 

1.3版本中,kubectl添加了一个completions的命令, 该命令可用于自动补全

通过以上方法进行配置了,便实现了kubectl的自动补全。

Continue reading "kubectl 命令自动补全"