节点

Kubernetes是主从结构，分为主节点和工作节点。

Master指集群控制节点，主节点。负责整个集群的管理和控制。在Master运行着以下关键进程：

API Server(kube-apiserver)：提供Http Rest接口的关键服务进程，是Kubernetes所有资源增删改查的唯一入口，也是集群控制的入口进程。
Controller Manager(kube-controller-manager)：Kubernetes所有资源对象的自动化控制中心，就像是资源对象的“大总管”。
Scheduler(kube-scheduler)：负责资源调度(Pod调度)的进程，相当于“调度室”。

Master需要部署etcd服务，因为Kubernetes所有资源对象数据保存在etcd中。高可用部署建议3台服务器部署Master。

除了Master，其他集群中的机器就称为Node，是集群中的工作负载节点。每个Node都会被Master分配一些工作负载(Docker容器)，当某个Node宕机时，其上面的工作负载就会被Master自动转移到其他Node上。在Node运行着以下关键进程：

kubelet：负责Pod对应的容器的创建、启动、停止等任务，同时与Master密切协作，实现集群的基本功能。
kube-proxy：实现Kubernetes Service的通信和负载均衡机制的重要组件。
Docker Engine：Docker引擎，负责本机的容器创建和管理工作。

Node可以在运行期间动态增加到Kubernetes集群中，默认情况下kubelet会向Master注册自己，定时向Master汇报自身信息，以及当前有哪些Pod在运行等。当超过一定时间，不上报信息时，Master就会将此Node标记为不可用，接着触发工作负载转移的自动流程。

查看Node：

kubectl get nodes

查看Node的详细信息：

kubectl describe node Node-NAME

命名空间

Kubernetes可以创建多个虚拟集群，称为命名空间 (namespace)，用于实现多租户的资源隔离，通过将集群内部的资源对象分配到不同的namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同分组在共享集群资源的同时可以被分别管理。如果没有明确定义的命名空间，集群将在始终存在的默认命名空间(default)中创建。

查看命名空间

kubectl get namespace

创建命名空间

kubectl create namespace test-zjh

删除命名空间

kubectl delete namespace test-zjh

资源对象

我们可以采用YAML或JSON格式定义或创建一个 Kubernetes 资源对象

kubectl apply -f ./my-manifest.yaml           # 创建资源
kubectl apply -f ./my1.yaml -f ./my2.yaml     # 使用多个文件创建
kubectl apply -f ./dir                        # 基于目录下的所有清单文件创建资源
kubectl apply -f https://git.io/vPieo         # 从 URL 中创建资源

类别	名称
资源对象	Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling、Node、Namespace、Service、Ingress、Label、CustomResourceDefinition
存储对象	Volume、PersistentVolume、Secret、ConfigMap
策略对象	SecurityContext、ResourceQuota、LimitRange
身份对象	ServiceAccount、Role、ClusterRole

以上列举的内容都是 kubernetes 中的 Object，这些对象都可以在 yaml 文件中作为一种 API 类型来配置。在想要创建的 Kubernetes 对象对应的 .yaml 文件中，必须配置如下的字段：

apiVersion - 创建该对象所使用的 Kubernetes API 的版本
kind - 想要创建的对象的类型
metadata - 帮助识别对象唯一性的数据，包括一个 name 字符串、UID 和可选的 namespace
也需要提供对象的 spec 字段。对象 spec 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。

容器集(Pod)

Kubernetes 中的逻辑而非物理的工作单位（最基本单位）称为 Pod。Pod 是包含一个或多个容器的容器组。同一容器集中的所有容器共享同一个 IP 地址、IPC、主机名称及其它资源。每个 Pod 都会包含一个特殊的Pause容器(根容器)，再加上一个或多个用户的业务容器。 Pause容器的作用就是提供IP等资源共享给业务容器的。

例，定义一个Nginx的Pod：

apiVersion: v1 # API版本
kind: Pod # 指定资源对象类型为 Pod
metadata:
  name: zjh-nginx # Pod的名称
  labels: # 指定标签，自定义key-value(可多个)，用于查询和筛选
    app: test-nginx
spec: # 容器组定义
  containers:
    - name: web
      image: nginx:latest
      ports:
        - containerPort: 80

保存为 zjh-nginx.yaml

部署Pod：

kubectl apply -f ./zjh-nginx.yaml -n test-zjh  # -n 指定命名空间

查看Pod：

kubectl get pod -n test-zjh -o wide # -o wide 显示更详细的信息
kubectl get pod -n test-zjh -o yaml # -o yaml 获取pod的yaml

查看日志：

kubectl logs zjh-nginx -n test-zjh -f

删除Pod：

kubectl delete pod zjh-nginx -n test-zjh

测试访问nginx服务(目前只能在Kubernetes集群内访问)：

控制器(Controller)

Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为。控制器包括有 Deployment，StatefulSet，DaemonSet，Replication Controller，Replica Set，Job，Cron Job， Horizontal Pod Autoscaling，Admission Controller。

Deployment

Deployment 是 Kubernetes 在1.2版本引入的新概念，内部使用了 Replica Set 来实现目的，为 Pod 和 ReplicaSet 提供了一个声明式定义（declarative）方法，用来替代以前的 Replication Controller（RC）来方便的管理应用，可以看作是RC的一次升级。典型的应用场景包括：

定义 Deployment 来创建 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment

例，定义一个Nginx的Deployment ：

apiVersion: apps/v1 # API版本
kind: Deployment # 资源对象类型为 Deployment
metadata:
  name: zjh-nginx # Deployment的名称
spec:
  selector: # 定位需要管理的 Pod，通过Pod的labels标签定位
    matchLabels:
      app: test-nginx
  replicas: 3 # 要部署的个数，k8s自动扩容分配
  template: # 要部署的 Pod
    metadata:
      labels:
        app: test-nginx
    spec:
      containers:
        - name: web
          image: nginx:latest
          ports:
            - containerPort: 80

重新保存为 zjh-nginx.yaml

部署Deployment ：

kubectl apply -f ./zjh-nginx.yaml -n test-zjh  # -n 指定命名空间

查看Pod：

kubectl get pods -n test-zjh -o wide -l 'app=test-nginx' # -l 指定labels

查看Deployment ：

kubectl get deploy -n test-zjh -o wide

测试删除一个pod：

kubectl delete pod zjh-nginx-7b9f67656d-446k2 -n test-zjh

发现会自动重新部署一个新的Pod：

扩容：

kubectl scale deployment zjh-nginx -n test-zjh --replicas 4 # 扩容为4个

删除Deployment ：

kubectl delete deployment zjh-nginx -n test-zjh

服务发现

Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。

Service

Serivce （svc）可以理解为微服务架构中的一个微服务，Serivce 定义了一个服务的访问入口地址，通过这个入口地址访问其背后的一组由 Pod 副本组成的集群实例。比如，我们用 Deployment 部署了一个集群服务（有很多Pod），Serivce 就是为我们提供访问入口，Serivce 会发现到其中一个 Pod 进行调用。

例，定义一个Nginx的 Serivce ：

apiVersion: apps/v1 # API版本
kind: Deployment # 资源对象类型为 Deployment
metadata:
  name: zjh-nginx # Deployment的名称
spec:
  selector: # 定位需要管理的 Pod，通过Pod的labels标签定位
    matchLabels:
      app: test-nginx
  replicas: 3 # 要部署的个数，k8s自动扩容分配
  template: # 要部署的 Pod
    metadata:
      labels:
        app: test-nginx
    spec:
      containers:
        - name: web
          image: nginx:latest
          ports:
            - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  ports:
    - port: 80 # Service虚端口
      targetPort: 80 # 容器端口
      nodePort: 33088 # 暴露端口
  selector: # 指定如何选择 Pod
    app: test-nginx
  type: NodePort # 指定为Node的IP地址

重新保存为 zjh-nginx.yaml

部署Serivce ：

kubectl apply -f ./zjh-nginx.yaml -n test-zjh  # -n 指定命名空间

查看Serivce ：

kubectl get svc -n test-zjh -o wide

浏览器访问：

最后

感谢您的阅读，更多分享请关注公众号【寻寻觅觅的Gopher】

Kubernetes 入门笔记

节点