pod

在大部分情况下，Pod只是容器的载体，通常我们会使用Deployment,RC,Job，ReplicaSet等对象来完成一组Pod的调度和控制。 当我们创建一个deployment或者RC后，kuernetes会自动根据我们的要求将一个或多个Pod副本自动调度到合适的节点上，这个过程kube-scheduler经过一系列算法自动完成，用户无法干预。在某些场景，我们也可以使用Kubernetes提供的其他调度策略来满足我们的特殊需求。这些调度策略包括： NodeSelector NodeAffinity PodAffinity Pod驱逐 Taints和Tolerations 参考链接 NodeSelector 定向调度 NodeSelector非常简单，就是将pod调度到我们指定的Node节点上，这里分为两个步骤： （1） 对Node节点打上特定的label （2） 创建pod时指定此label. 下面是一个简单示例： 1、对node添加标签,并验证： kubectl label nodes <node-name> <label-key>=<label-value> eg: [root@node-1 ~]# kubectl get node NAME STATUS ROLES AGE VERSION 10.0.0.2 Ready <none> 9d v1.10.4 10.0.0.3

kubectl get 1.查询节点，nodes or node or no $ kubectl get no NAME STATUS ROLES AGE VERSION master1 Ready master 16h v1.9.2 master2 Ready master 16h v1.9.2 master3 Ready master 16h v1.9.2 2.查询组件状态，componentstatuses or cs $ kubectl get cs NAME STATUS MESSAGE ERROR controller-manager Healthy ok scheduler Healthy ok etcd-2 Healthy {"health":"true"} etcd-1 Healthy {"health":"true"} etcd-0 Healthy {"health":"true"} 3.查询名命空间，namespaces or ns $ kubectl get ns NAME STATUS AGE default Active 18h kube-public Active 18h kube-system Active 18h 下面所有查询，缺省defalut名命空间，-n 指定名命空间，指定全部名命空间 --all-namespaces 4.查询pod

1. 简介 k8s 的 API Server 提供了 RESTful 风格的网关接口, 允许用户通过这个接口向 k8s 集群发起请求。如创建一个 Pod 或销毁一个 Pod 等操作 用户可以通过编程语言遵循 API Server 提供的网关接口规范和 API Server 进行通信, 也可以通过 k8s 自带的 kubectl 命令和 API Server 进行通信, 或者通过由 Dashboard 提供的 Web UI 和 API Server 进行通信 其中 kubectl 是官方提供的用于和 API Server 通信的 CLI 工具, 且是最为常用的交互式命令行工具 2. kubectl 2.1. 查看命令帮助 # 查看 kubectl 命令帮助 [root@master ~]# kubectl --help # 基础命令(适合初学者使用) Basic Commands (Beginner): create 创建资源, k8s 支持从 yaml 文件或者命令行参数直接创建资源 expose 暴露服务 run 运行 Pod set 设置对象属性 # 基础命令 Basic Commands (Intermediate): explain get 获取资源信息 edit 编辑资源 delete 删除资源 # 部署命令 Deploy Commands: rollout 更新管理

Kubernets 中的Node, Pod，Replication Controller, Service 等都可以看作一种资源对象，这些资源几乎都可以通过使用Kubernetes提供的kubectl 工具执行增删改查，并将其保存在etcd中持久化储存。通过跟踪对比etcd库中保存的“资源预设状态”与当前环境中的实际资源状态进行对比，对差异资源状态进行纠错，来实现自动控制集群状态的功能。下面将分别介绍这个组件角色。 管理角色 Kubernetes中有两种管理角色，Master和Node. Master Master是Kubernetes集群的控制节点，所有对于Kubernetes的命令操作都需要在控制节点执行。Master一般运行如下进程： kube-apiserver： Kubernetes API Server, 提供了HTTP Rest接口的关键服务进程，是所有资源增，删，改，查的入口，也是集群控制的入口进程，kubectl是直接与 API Server交互的，默认监听 6443端口。 kube-controller-manager: 每个资源一般都对应有一个控制器，而controller manager就是负责管理这些控制器的,它是自动化的循环控制器，是Kubernetes的核心控制守护进程。默认监听10252端口。 kube-scheduler ：

本文将帮助你厘清在Kubernetes中调试 deployment的思路。下图是完整的故障排查思路，如果你想获得更清晰的图片，请在公众号后台（RancherLabs）回复“ troubleshooting ”。 当你希望在Kubernetes中部署一个应用程序，你通常需要定义三个组件： Deployment——这是创建名为Pods的应用程序副本的方法 Serivce——内部负载均衡器，将流量路由到Pods Ingress——可以描述流量如何从集群外部流向Service 接下来，我们通过图片快速回顾一下。 在Kubernetes中，你的应用程序通过两层负载均衡器暴露：内部和外部。 内部负载均衡器称为Service，而外部负载均衡器则称为Ingress。 Pod未直接部署，因此，Deployment创建Pod并监视它们。 假设你想部署一个简单的Hello World应用程序，那么对于此类应用程序，其YAML文件与以下类似： apiVersion: apps/v1 kind: Deployment metadata: name: my-deployment labels: track: canary spec: selector: matchLabels: any-name: my-app template: metadata: labels: any-name: my-app spec

k8s数据持久化 Docker容器是有生命周期的，因此数据卷可以实现数据持久化 数据卷主要解决的问题： 数据持久性：当我们写入数据时，文件都是暂时性的存在，当容器崩溃后，host就会将这个容器杀死，然后重新从镜像创建容器，数据就会丢失 数据共享：在同一个Pod中运行容器，会存在共享文件的需求 存储类 （Storage class）是k8s资源类型的一种，它是有管理员为管理PV更加方便创建的一个逻辑组，可以按照存储系统的性能高低，或者综合服务质量，备份策略等分类。不过k8s本身不知道类别到底是什么，它这是作为一个描述。 存储类的好处之一就是支持PV的动态创建，当用户用到持久性存储时，不必再去提前创建PV，而是直接创建PVC就可以了，非常的方便。 存储类对象的名称很重要，并且出了名称之外，还有3个关键字段 Provisioner（供给方）: 及提供了存储资源的存储系统。k8s内建有多重供给方，这些供给方的名字都以“kubernetes.io”为前缀。并且还可以自定义。 Parameters(参数)：存储类使用参数描述要关联到的存储卷，注意不同的供给方参数也不同。 reclaimPolicy:PV的回收策略，可用值有Delete(默认)和Retain Volume： emptyDir（空目录）： 使用情况比较少，一般只做临时使用，类似Docker数据 持久化的：docker

作者 | 陈显鹭 阿里巴巴高级技术专家 本文整理自《CNCF x Alibaba 云原生技术公开课》第 23 讲，点击“阅读原文”直达课程页面。<br />关注“阿里巴巴云原生”公众号，回复关键词 “入门” ，即可下载从零入门 K8s 系列文章 PPT。 导读 ：在 Kubernetes 里面， API 编程范式也就是 Custom Resources Definition(CRD)。我们常讲的 CRD，其实指的就是用户自定义资源。为什么会存在用户自定义资源问题呢？本文将会从其需求来源出发，对此概念进行逐步深入的讲解。 一、需求来源 首先我们先来看一下 API 编程范式的需求来源。 在 Kubernetes 里面， API 编程范式也就是 Custom Resources Definition(CRD)。我们常讲的 CRD，其实指的就是用户自定义资源。 为什么会有用户自定义资源问题呢？ 随着 Kubernetes 使用的越来越多，用户自定义资源的需求也会越来越多。而 Kubernetes 提供的聚合各个子资源的功能，已经不能满足日益增长的广泛需求了。用户希望提供一种用户自定义的资源，把各个子资源全部聚合起来。但 Kubernetes 原生资源的扩展和使用比较复杂，因此诞生了用户自定义资源这么一个功能。 二、用例解读 CRD 的一个实例 我们首先具体地介绍一下 CRD 是什么。

Ingress实现虚拟主机的方案 环境介绍 主机 IP地址 服务 master 192.168.1.21 k8s node01 192.168.1.22 k8s node02 192.168.1.23 k8s 基于[ https://blog.51cto.com/14320361/2464655 ]() 的实验继续进行 1、首先确定要运行ingress-nginx-controller服务。 在gitbub上找到所需的ingress的yaml文件 4. master下载 [root@master ingress]# wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.29.0/deploy/static/mandatory.yaml 5. 修改 mandatory.yaml 文件 [root@master ingress]# vim mandatory.yaml hostNetwork: true #213 （1）执行一下 [root@master ingress]# kubectl apply -f mandatory.yaml （2）查看一下 [root@master ingress]# kubectl get pod -n ingress-nginx 2、将ingress-nginx

PLEG(PodLifecycleEventGenerator)主要是用于周期性检测Pod的运行状态，从而对比Pod前后状态生成事件从而触发kubelet进行Pod容器状态的校证,让我们一起来初探下其内部实现机制 1. 图解设计 1.1 Pod事件生成 Pod事件生成主要是根据对应Pod前后的状态对比来实现，首先通过runtime来获取当前节点的所有Pod的列表，并将对应的状态进行保存，这样在下一个轮训周期就可以通过前后状态的对比去发现状态发生改变的Pod的容器，并且产生对应的事件 1.2 事件通知与状态同步 Pod事件生成之后会通过管道将对应的事件同步给状态同步线程，状态同步线程感知到Pod的变更事件后，会与Pod的目标状态进行对比同步，并调用Runtime来进行最终校证操作的执行，同时在下个轮询周期中又会重新从Runtime获取状态，从而不断校证Pod的状态，直至目标状态 2. Pod记录 Pod记录其实就是一个map，并通过podRecord来保存前后轮询周期Runtime返回的Pod的信息 type podRecord struct { old *kubecontainer.Pod current *kubecontainer.Pod } type podRecords map[types.UID]*podRecord 3. Pod事件生成器 3.1 获取Pod状态

Introduction 所谓的云原生应用，能够清楚自己运行在k8s上，并且使用k8s api 和资源当作其扩展。 一方面，云原生应用能够轻便地在不同的云上迁移。另一方面，受益于k8s提供的简洁可定义声明式api。 Extension Patterns cloud providers: in-tree controller manager: kubelet: network, devices, storage, container runtimes extend kubectl with plugins extensions in the API server, dynamic admission control with webhook Custom resources and custom controllers. custom apiserver scheduler extensions. Controllers and operators controller: 实现了一个控制循环，从API server监听到的集群状态，并且把当前状态调整到预期状态。 operator: 是指controller+ 自定义资源的方式，去做像应用生命周期管理相关的一些操作。 the controller loop 读取资源的状态，更倾向于事件驱动。 改变集群或外部集群的对象的状态。