K8s基础操作和名称解释

pod

kubectl run nginx1 --image nginx --port 80 #创建pod

[root@master ~]# kubectl get pod # 查看pod
NAME                      READY   STATUS    RESTARTS   AGE
nginx-554b9c67f9-244gh    1/1     Running   1          2d10h
nginx1-5fd6585797-fxdgz   1/1     Running   0          55s

[root@master ~]# kubectl get pod -w  # 动态刷新 --watch
NAME                      READY   STATUS              RESTARTS   AGE
nginx-554b9c67f9-244gh    1/1     Running             1          2d10h
nginx1-5fd6585797-fxdgz   0/1     ContainerCreating   0          22s
nginx1-5fd6585797-fxdgz   1/1     Running             0          32s

[root@master ~]# kubectl get deployment  #(简写deploy)
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
nginx    1/1     1            1           2d10h
nginx1   1/1     1            1           81s

[root@master ~]# kubectl get deploy/nginx
NAME    READY   UP-TO-DATE   AVAILABLE   AGE
nginx   1/1     1            1           2d10h

[root@master ~]# kubectl get deploy/nginx1 -o wide #列出指定pod信息
NAME     READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS   IMAGES   SELECTOR
nginx1   1/1     1            1           2m28s   nginx1       nginx    run=nginx1

[root@master ~]# kubectl get pod -owide # 列出所有pod详细信息
NAME                      READY   STATUS    RESTARTS   AGE     IP           NODE    NOMINATED NODE   READINESS GATES
nginx-554b9c67f9-244gh    1/1     Running   1          2d10h   10.244.1.4   node1   <none>           <none>
nginx1-5fd6585797-fxdgz   1/1     Running   0          2m50s   10.244.2.2   node2   <none>           <none>

kubectl scale deployment nginx1 --replicas=2 #扩展pod下容器个数

• 生成deployment的yaml文件

  kubectl create deployment nginx --image=nginx --dry-run -o yaml > deployment.yaml

• 生成svc的yaml文件

  kubectl expose deployment nginx --port=80 --target-port=80 --type=NodePort --dry-run -o yaml > service.yaml

• 修改已运行的pod、svc

  kubectl edit svc svc-name
  kubectl edit deployment deployment-name

namespace

# kubectl可以通过–namespace或者-n选项指定namespace。如果不指定，默认为default。
kubectl get namespaces # 缩写ns，查看命名空间

# 注意：namespace包含两种状态”Active”和”Terminating”。在namespace删除过程中，namespace状态被设置成”Terminating”。

# 命令行直接创建
kubectl create namespace new-namespace

# 通过文件创建
$ cat my-namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: new-namespace

$ kubectl create -f ./my-namespace.yaml

# 删除
$ kubectl delete namespaces new-namespace
# 注意：
删除一个namespace会自动删除所有属于该namespace的资源。
default和kube-system命名空间不可删除。

---

Replication Controller

就像一个进程管理器，监管着不同'node'上的多个pod。保持特定数量的pod副本运行。
Replication Controller只会对那些RestartPolicy = Always的Pod的生效，（RestartPolicy的默认值就是Always）,Replication Controller不会去管理那些有不同启动策略pod。

Scaling（缩放）

Replication Controller让我们更容易的控制pod的副本的数量，不管我们是手动控制还是通过其它的自动管理的工具.
最简单的：修改replicas的值

Rolling updates（动态更新）

Replication Controller
可以支持动态更新，当我们更新一个服务的时候，它可以允许我们一个一个的替换pod

Node

'Node'是Pod真正运行的主机，可以物理机，也可以是虚拟机。
为了管理Pod，每个node节点上至少要运行container runtime（比如docker或者rkt）、kubelet和kube-proxy服务。

Node管理

不像其他的资源（如Pod和Namespace），Node本质上不是Kubernetes来创建的，Kubernetes只是管理Node上的资源。
虽然可以通过Manifest创建一个Node对象（如下json所示），但Kubernetes也只是去检查是否真的是有这么一个Node，如果检查失败，也不会往上调度Pod。

ReplicaSets

ReplicaSet是下一代复本控制器。
ReplicaSet和 Replication Controller之间的唯一区别是现在的选择器支持。
Replication Controller只支持基于等式的selector（env=dev或environment!=qa）;
但ReplicaSet还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)）。

Services

# 相当于负载均衡，后面是pod。
Kubernete Service 是一个定义了一组Pod的策略的抽象，我们也有时候叫做宏观服务。
每个pod都由自己的ip，这些IP也随着时间的变化也不能持续依赖。这样就引发了一个问题：如果一些Pods（让我们叫它作后台，后端）提供了一些功能供其它的Pod使用（让我们叫作前台），在kubernete集群中是如何实现让这些前台能够持续的追踪到这些后台的？
Service

如果你选择了“NodePort”，那么 Kubernetes master 会分配一个区域范围内，（默认是30000-32767），并且，每一个node，都会代理（proxy）这个端口到你的服务中，我们可以在spec.ports[*].nodePort 找到具体的值

Volumes

# 解决pod的持久化存储数据，以及数据文件共享
Kubernetes volume 支持多种类型，任何容器都可以使用多个Kubernetes volume。
它的核心，一个 volume 就是一个目录，可能包含一些数据，这些数据对pod中的所有容器都是可用的，这个目录怎么使用，什么类型，由什么组成都是由特殊的volume 类型决定的

想要使用一个volume，Pod必须指明Pod提供了那些磁盘，并且说明如何挂在到容器中

PV/PVC/StorageClass

PersistentVolume（PV）是集群中已由管理员配置的一段网络存储。 集群中的资源就像一个节点是一个集群资源。 PV是诸如卷之类的卷插件，但是具有独立于使用PV的任何单个pod的生命周期。 
PersistentVolumeClaim（PVC）是用户存储的请求。 它类似于pod。Pod消耗节点资源，PVC消耗存储资源。 pod可以请求特定级别的资源（CPU和内存）。
StorageClass为管理员提供了一种描述他们提供的存储的“类”的方法。 不同的类可能映射到服务质量级别，或备份策略，或者由群集管理员确定的任意策略。

PV是集群中的资源。 PVC是对这些资源的请求，也是对资源的索赔检查。
PV和PVC之间的相互作用遵循这个生命周期:
Provisioning ——-> Binding ——–>Using——>Releasing——>Recycling
Provisioning

Deployment

Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法.
用来替代以前的ReplicationController来方便的管理应用。
    - 定义Deployment来创建Pod和ReplicaSet
    - 滚动升级和回滚应用
    - 扩容和缩容
    - 暂停和继续Deployment

Deployment为Pod和Replica Set（下一代Replication Controller）提供声明式更新。
你只需要在Deployment中描述你想要的目标状态是什么，Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。
你可以定义一个全新的Deployment，也可以创建一个新的替换旧的Deployment。