标签是一种简单却又功能强大的kubernetes特性，不仅可以组织pod，也可以组织所有其他的kubernetes资源，标签是可以附加到资源的任意键值对，用以选择具有该确切标签的资源，只要标签的key在资源内是唯一的，一个资源便可以拥有多个标签。
Kubernetes 中所有的内容都抽象为资源，资源实例化（被调用、被执行了）之后，叫做对象。
当然最基础的我就一笔带过： 查看帮助： [root@master1 ~]# kubectl --help 查看版本：（至今，yum安装的版本竟然是1.5.2，，这两天准备升级到1.8x） [[email protected] ~]# kubectl --version Kubernetes v1.5.2 get get命令用于获取集群的一个或一些resource信息。 使用–help查看详细信息。 Ps：kubectl的帮助信息、示例相当详细，而且简单易懂。建议大家习惯使用帮助信息。kubectl可以列出集
如果配置文件中的sh改成一个不存在的比如shxxx，且restartPolicy一直未Never的话那么就会一直创建不了，报ContainerCannotRun，也仍然会一直创建；如果restartPolicy改为OnFailure,那么就会一直重启，RESTARTS会一直增加
尽管只能在单个容器上指定请求和限制，但是谈论Pod资源请求和限制很方便。特定资源类型的 Pod资源请求/限制是Pod中每个Container的该类
使用 node affinity 调度，创建一个新的 yaml 文件 nadeploy2.yaml
APIserver符合RESTful风格，支持GET/PUT/DELETE/POST等各种操作。所以也支持kubectl通过一系列命令对各处资源进行管理控制。 常用的资源 1)、workLoad(工作负载型资源，运行APP，对外提供服务): Pod/ReplicaSet/Deployment/ StatefulSet/ DaemonSet/ Job/ Cronjob / 2)、service discovery and Load Balance(服务发现及均衡型资源)：Service/ Ingress 3)、configuration and storage(配置与存储类型资源) ：Volume,CSI(容器存储接口，扩展第三方的存储) ConfigMap，Secret(特殊的配置类型资源) Downward API(配置类型资源) 4)、集群级资源(配置在名称空间级别)： namespace, node, role, clusterRole, roleBinding, clusterRoleBinding 5)、元数据类型资源：HPA、PodTemplate、limitRange（读取权限)
用于确保由其掌控的Pod对象副本数量，能够满足用户期望，多则删除，少则通过模板创建。
StatefulSet 旨在与有状态的应用及分布式系统一起使用。本节将通过使用 StatefulSet 部署一个简单的 Web 应用，来演示StatefulSet的常规操作，包括：
1、command：指定在一个或多个资源上要执行的操作。例如：create、get、describe、delete、apply等
网络策略-------理解为防火墙 图片1.png [root@vms61 chap10-net]# kubectl run pod1 --image=nginx --image-pull-policy=IfNotPresent --labels="name=pod1" pod/pod1 created [root@vms61 chap10-net]# kubectl run pod2 --image=nginx --image-pull-policy=IfNotPresent --labels="nam
version命令用于确认客户端和服务器侧的版本信息，不同的版本的情况变化可能很大，所以故障排除时首先也需要确认的是现场环境的版本信息。从下面可以清楚地看到，本文验证时所使用的版本为1.11.2
get命令用于获取集群的一个或一些resource信息。 使用–help查看详细信息。 Ps：kubectl的帮助信息、示例相当详细，而且简单易懂。建议大家习惯使用帮助信息。kubectl可以列出集群所有resource的详细。resource包括集群节点、运行的pod，ReplicationController，service等。
[root@k8s-master ~]# kubectl create -f read.yaml
可见，这个 nginx 并没有创建在 master 节点， 而是 slave 节点去了。
本章节将介绍如何在kubernetes集群中部署一个nginx服务，并且能够对其进行访问。
Kubernetes中有各种各样的组件,对于容器来说Kubernetes最小的单元是由Pod进行组成的,但是我们在使用过程中经常会使用到Deployment来部署我们的应用,其中究竟区别在哪里,我们今天就来一同探索
创建部署之后，可以看到容器已经运行了，但是默认情况下，容器只能内部互相访问，如果需要对外提供服务，有以下几种方式：
这里简单说明：kubernetes-bootcamp为实例名，–image指定docker镜像，–port指定对外提供的端口
[root@master ~]# kubectl get nodes 查看集群节点 NAME STATUS AGE node1 Ready 25m node2 Ready 19m [root@master ~]# kubectl version 查看版本 Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.2", GitCommit:"269f928217957e7126dc87e6adfa82242bfe5b1e", GitTreeState:"clean", BuildDate:"2017-07-03T15:31:10Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"} [root@master ~]# kubectl run nginx --image=docker.io/nginx --replicas=1 --port=9000 deployment "nginx" created [root@master ~]# kubectl get deployment NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE nginx 1 1 1 0 15s [root@master ~]# kubectl get pods NAME READY STATUS RESTARTS AGE nginx-2187705812-8r0h4 1/1 Running 0 1h [root@master ~]# kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE nginx-2187705812-8r0h4 1/1 Running 0 1h 10.255.4.2 node1 想要删除一个容器的时候：
Pod是Kubernetes中能够创建和部署的最小单元，是Kubernetes集群中的一个应用实例，总是部署在同一个节点Node上。Pod中包含了一个或多个容器，还包括了存储、网络等各个容器共享的资源。Pod支持多种容器环境，Docker则是最流行的容器环境。
在 kubernetes 中，Deployment、DaemonSet会持续运行任务，这些 pod 中的进程在崩溃退出时会重新启动，永远达不到完成态。你也许会遇到这样的场景，当需要运行一个一次性的可完成的任务，其进程终止后，不应该再重新启动，那么 Job 资源类型完全符合你。Kubernetes 中通过 Job 资源提供了对此的支持，它允许你运行一种 pod，该 pod 在内部进程成功结束时，不重启容器。一旦任务完成，pod 就被认为处于完成状态。在发生节点故障时，该节点上由 Job 管理的 pod 将按照 ReplicaSet 的 pod 的方式， 重新安排到其他节点，以确保任务能够成功完成，所以 Job 通常用于执行一次性任务或批处理作业。Job 还可以控制 Pod 的数量，确保一定数量的 Pod 成功完成任务。Job 的一些常用使用场景：
版权声明：本文为耕耘实录原创文章，各大自媒体平台同步更新。欢迎转载，转载请注明出处，谢谢
一旦运行了 Kubernetes 集群，就可以在其上部署容器化应用程序。为此，您需要创建 Kubernetes Deployment 配置。Deployment 指挥 Kubernetes 如何创建和更新应用程序的实例。创建 Deployment 后，Kubernetes master 将应用程序实例调度到集群中的各个节点上。
探测的目的: 用来维持 pod的健壮性,当pod挂掉之后，deployment会生成新的pod,但如果pod是正常运行的，但pod里面出了问题，此时deployment是监测不到的。故此需要探测(probe)-pod是不是正常提供服务的
K8S 1.17.x 之前创建deploy的命令选项很多，但从1.18.x开始就变得少了
我们之前通过资源配置清单，自己创建了一个Pod资源，如果此时这个Pod被删除了，K8S是不会帮我们重新创建的。通过这种方式创建的Pod称之为自主式Pod资源，如果线上所有的服务都需要我们来手动管理Pod，那将是一个巨大的运维开销，那K8S就失去了其存在的意义，所以，K8S为我们提供了Pod控制器资源,专门用于对Pod的管理。Pod控制器可以帮我们自动保持Pod状态处于我们期望的状态，例如Pod的副本数，Pod中使用的容器镜像版本，Pod的更新策略等等。
我们一般将pod对象从创建至终的这段时间范围称为pod的生命周期，它主要包含下面的过程：
# 1.编辑nginx-deployment.yaml 点击查看 apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx
在《研发工程师玩转Kubernetes——使用Node特性定向调度Pod》中，我们提到requiredDuringSchedulingIgnoredDuringExecution只有在规则被满足的时候才能执行调度。本节我们将测试几种边界情况，看看Kubernetes的行为。
众多周知，Kubernetes Scheduler 是 Kubernetes中负责Pod调度的重要功能模块，运行在k8s 集群中的master节点。
Kubernetes是一个来管理容器化应用程序的开源平台。如果您使用Docker将应用部署到多个服务器节点上，Kubernetes集群就可以管理您的服务器和应用，包括扩展、部署和滚动更新等操作。
了解了Pod的基础知识之后，对于实验来说可以通过kubectl run或者apply一个yaml来创建Pod，但是对于生产环境中构建一个CNF来说，有些Pod需要多个副本，有的运行完就不再需要了，有些需要定期执行某些任务，有些需要在不同的node上只创建一个Pod，这样通过一个一个的创建Pod是不仅费时费力且不便于维护，因此需要一个概念来根据不同需求创建对应的Pod并确保在任何时候都有对应要求的副本在运行，这个概念便是Pod的控制器。
StatefulSet副本启动顺序按照名称0，1，2，只有web-0完全启动之后才会启动web-1，web-1完全启动之后才会启动web-2
可以看到最后的是 FailedScheduling , 原因是 0/1 nodes are available: 1 node(s) had taint {node-role.kubernetes.io/master: }, that the pod didn't tolerate.
ELK的Pod会暴露两个服务，一个暴露logstash的5044端口，给filebeat用，另一个暴露kibana的5601端口，给搜索日志的用户访问的时候用；
在《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》中我们看到Kubernetes会一直等待Node状态恢复。这节我们将做实验，看看Node恢复后Kubernetes的表现。 仍然借助《研发工程师玩转Kubernetes——Node失效后的Pod的调度实验》的实验过程。
关于POD，还需要了解一个重要的概念就是它的生命周期，一个POD通常都有控制管理器，比如ReplicaSet、Deployment、DaemonSets等，单独创建一个Pod的时候是不受任何管理器管理的，不管是哪种情况，POD都要经历不同的生命周期阶段：
Kubernetes从1.2版本开始支持批处理类型的应用,我们可以通过Kubernetes Job资源对象来定义并启动一个批处理任务。
容器实例服务（Container Instance Service , CIS）可以帮您在云上快捷、灵活的部署容器，让您专注于构建程序和使用容器而非管理设备上。无需预购 CVM，您就可以在几秒内启动一批容器来执行任务。您也可以通过 kubernetes API 把已有 kubernetes 集群的 pod 调度到 CIS 上以处理突增业务。CIS 根据您实际使用的资源计费，可以帮您节约计算成本。使用 CIS 可以极大降低您部署容器的门槛，降低您执行 batch 型任务或处理业务突增的成本。
在《研发工程师玩转Kubernetes——PVC通过storageClassName进行延迟绑定》一文中，我们利用Node亲和性，让Pod部署在节点ubuntud上。因为Pod使用的PVC可以部署在节点ubuntuc或者ubuntud上，而系统为了让Pod可以部署成功，则让PVC与Pod亲和的ubuntud上的PV绑定。这样Pod在自身节点亲和性和PVC上都满足了条件。
新手学习 K8s 最大的难度感觉是在起步动手实践的时候，Pod 没有正常启动起来，或者运行了一段时间 Pod 自己崩溃了。那么是什么问题导致了它没运行起来，又或者是什么因素导致了它的崩溃，这到底是道德的沦丧还是人性的扭曲。。。不好意思，拿错脚本了。
在 Crunchy Data 担任解决方案架构师的角色中，我帮助客户使用 Crunchy Postgres for Kubernetes（CPK）快速上手。在 Kubernetes 中安装和管理 Postgres 集群从未如此简单。然而，有时事情不会按计划进行，我注意到一些 Kubernetes 安装可能出现问题的主要领域。今天，我想逐步介绍一些人们在尝试在 Kubernetes 中运行 Postgres 时经常遇到的常见问题，并提供一些基本的故障排除思路以便入门。当然，您的问题可能不在这里，但如果您只是想诊断安装失败或群集故障，这是我首选的入门故障排除清单。
用了Ansible，master节点为Controller控制节点，node工作节点为受控节点，下面为一个Ping测试
Replication Controller（复制控制器，RC）和ReplicaSet（复制集，RS）是两种简单部署Pod的方式。在生产环境中，主要使用更高级的Deployment等方式进行Pod的管理和部署。
通过 docker desktop 可以安装适用于单机和开发环境单机版的 K8S，如果 docker desktop 无法启动 Kubernates 通过以下方式解决：
每个Pod里运行着一个特殊的被称之为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此他们之间通信和数据交换更为高效。在设计时可以充分利用这一特性，将一组密切相关的服务进程放入同一个Pod中；同一个Pod里的容器之间仅需通过localhost就能互相通信。
Pod是kubernetes的最小管理单元，在kubernetes中，按照pod的创建方式可以将其分为两类：
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
