k8s核心组件&&kubectl命令的使用

pod分类

1、自助式pod
自我管理的pod，创建以后仍然需要提交给apiserver，由apiserver接收以后借助于调度器将其调度至指定的node节点，由node启动此pod。
如果此pod出现故障,需要重启容器则由kubelet来完成
如果node节点故障了，那么此pod将会消失。其无法实现全局调度。所以不推荐使用此种pod

2、控制器管理的pod
常见的pod控制器

• ReplicationController（复制控制器）
  当启动一个pod时,这个pod如果不够用可以再启一个副本，而后由控制器来管理同一类pod的各种副本与对象。一旦副本少了就会自动增加。采取多退少补的规则，精确符合我们所定义的期望。
  支持滚动更新
• ReplicaSet
  由一个名叫Deployment的声明式更新的控制器来管理
• Deployment
  Deployment只能管理无状态的应用
• StateFulSet
  有状态副本集，可以管理有状态的应用
• DaemonSet
  如果需要在每个node上运行一个副本的时候可以用DaemonSet
• Job
• Cronjob
• 以上每种控制器都是用来实现一种特定的应用管理的
  

核心组件

1. HPA

• HPA(HorizontalPodAutoscaler，水平pod自动伸缩控制器)
• Deployment还支持二级控制器
• 一般情况下我们可以确保一个node上有2个pod在运行，万一用户访问流量增加，2个pod不足以承载这么多访问量怎么办?此时我们就应该要增加pod资源，那么到底应该加几个?
  HPA控制器可自动监控pod、自动进行扩展。

3. service

• 服务发现 （集贸市场例子：注册摊位、声明地址）
• pod是有生命周期的，一个pod随时都有可能离去，随时都有可能会有其他pod加进来，假如它们提供的是同一种服务，客户端是无法通过固定的手段来访问这些pod的，因为pod本身是不固定的，它们随时可能被替换掉,无论使用主机名还是IP地址，都随时会被替换掉。为了尽可能的降低客户端与pod间协调的复杂度，k8s为每一组提供同类服务的pod和其客户端之间添加了一个中间层，这个中间层是固定的，这个中间层就叫service
• service只要不被删除，其地址与名称皆是固定的，当客户端需要在其配置文件中写上访问某个服务时，它不再需要自动发现，只需要在配置文件中写明service的名称即可，而这个service是个调度器，其不但能够提供一个稳定的访问入口，还可以做反向代理,当service接收到客户端的请求后，会将其代理到后端的pod之上，一旦pod宕机了会立即新建一个pod，这个新建的pod会立即被service关联上，作为service后端的可用pod之一
• 客户端程序访问服务都是通过IP+端口或者主机名+端口的方式来实现的。而service关联后端的pod不是靠它的IP和主机名，而是靠pod的标签选择器。只要创建的pod的label是统一的，无论P地址和主机如何改变，其都能被service所识别。如此一来，只要pod属于标签选择器，只要其在service的管理范围之内，则其就会被关联到service中，当这个动态的pod关联到service中之后，再进行动态的探测此pod的IP地址、端口，再将其作为自己后端可调度的可用服务器主机对象。因此，客户端的请求发送到service，然后由service代理到后端真实的pod中的容器进行响应。
• service不是一个程序，也不是一个组件，它只是一个iptables的dnat规则
  service作为k8s的对象,有其自身的名称，而service的名称相当于服务的名称，而这个名称可以被解析。

3.Replication Controller
简称RC，是k8s的核心概念之一，定义了期望值的场景，声明的某种Pod的副本数量在任意时刻符合特定的值，包括：
replicas Pod的期望副本数，就是一个容器显示几个，手动设置。
Lable Selector 筛选目标Pod

• etcd保存了整个集群的状态；
• apiserver提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制；
• controller manager负责维护集群的状态，比如故障检测、自动扩展、滚动更新等；
• scheduler负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上；
• kubelet负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理；
• Container runtime负责镜像管理以及Pod和容器的真正运行（CRI）；
  kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；

K8s网络模型

• 节点网络
• service集群网络
• pod网络

k8s的三种网络模型分属于三个网段，由此延伸出来三个问题

• 同一pod内的多个容器间如何通信？

  • lop网卡
    

• 各pod之间如何通信？

  • 物理桥桥接，规模大的情况下会产生广播风暴（很少用这种方式）
  • Overlay Network，通过隧道的方式转发报文（基本上都会用这个方式）
    

• pod与service之间如何通信？

Kubectl管理工具

kuberconfig配置文件
kubectl使用kubeconfig认证文件连接k8s集群，使用kubectl config指令生成kubeconfig文件。

//集群
apiVersion:v1
kind:Config
clusters:
- cluster:
   certificate-authority-data:
   server:https://192.168.31.61:6443
name:kubernetes

//上下文
contexts:
- context:
  cluster:kubernetes
  user:kubernetes-admin
name:kubernetes-admin@kubernetes

kubectl命令

run

//启动一个pod
[root@master ~]# kubectl run nginx --image nginx
podinx created
[root@master ~]# kubectl get pods
NAME    READY   STATUS    RESTARTS   AGE
nginx   1/1     Running   0          2m52s
[root@master ~]# kubectl get pods -o wide
NAME    READY   STATUS    RESTARTS   AGE     IP            NODE                NOMINATED NODE   READINESS GATES
nginx   1/1     Running   0          3m43s   10.244.2.11   node2.example.com   <none>           <none>

//暴露端口号
[root@master ~]# kubectl run nginx --image nginx --port 80
podinx created

//加标签
[root@master ~]# kubectl run nginx --image nginx --labels "app=nginx,env=prod"
podinx created

//干跑模式,测试能否运行
[root@master ~]# kubectl run nginx --image nginx --dry-run server
W1219 10:14:28.790987 1379634 helpers.go:553] --dry-run is deprecated and can be replaced with --dry-run=client.
podinx created (dry run)
[root@master ~]# kubectl get pods
No resources found in default namespace.

create

创建一个来源一个文件或标准输入的资源

[root@master ~]# kubectl create deployment b1 --image busybox
deployment.apps/b1 created

//ContainerCreating，表示正在拉镜像
[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     ContainerCreating   0          10s

//CrashLoopBackOff，表示已经退出了，退出了并不代表没运行，它是运行之后退出了；因为busybox默认是打开/bin程序，而/bin一执行就退出了，跟容器里面一样的，一启动就退出了。
[root@master ~]# kubectl get pods
NAME                     READY   STATUS              RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     CrashLoopBackOff    3          102s

//使用这种方式，给它一个任务就不会运行完就退出
[root@master ~]# kubectl create deployment b3 --image busybox -- sleep 6000
deployment.apps/b3 created
[root@master ~]# kubectl get pods
NAME                     READY   STATUS             RESTARTS   AGE
b1-68578fbb6c-gzhn2      0/1     CrashLoopBackOff   7          14m
b2-75d5678b7f-76zpc      0/1     CrashLoopBackOff   7          13m
b3-84d7f7d4bf-lbcnh      1/1     Running            0          47s

• 创建多个pod
  kubectl create –image <镜像> --replicas <启动pod的数量>，这里我们创建的是deployment无状态）类型的，replicas是用来设置要启动多少pods

• 暴露端口号，用-- port <端口号>

get

获取node节点、pod、service信息

# 查看创建的pod
[root@master ~]# kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
web1-5756d98cd9-fh588   1/1     Running   0          2m1s

# 查看所有的service
[root@master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
kubernetes   ClusterIP   10.96.0.1        <none>        443/TCP        25h
my-dep       NodePort    10.97.89.122     <none>        80:32213/TCP   5m17s
nginx        ClusterIP   10.106.246.141   <none>        8000/TCP       15m

查看多个信息，用","隔开
[root@master ~]# kubectl get pod,svc
NAME                          READY   STATUS    RESTARTS   AGE
pod/my-dep-6fcbf46469-drs28   1/1     Running   0          36m
pod/nginx-85b98978db-9c9xs    1/1     Runn