k8s 基础 资源
k8s简介文档:https://www.yuque.com/fairy-era/yg511q/hg3u04学习视频是b站的黑马视频。k8s组成部分,组件一个K8s集群主要是由控制节点(master),工作节点(node)构成,每个节点会安排不同的组件。master的组件:Kublet: k8s的后端程序,用来启动对应容器。Apiserver是资源操作的唯一入口,接受用户输入的命令,提供认证授权等等
k8s简介
文档:https://www.yuque.com/fairy-era/yg511q/hg3u04
学习视频是b站的黑马视频。
前言
现在基本部署都是容器化部署,虽说容器化部署很方便,但也会有一些问题,比如:
- 一个容器故障停机了,怎么样让另外一个容器立刻启动去替补停机的容器
- 当并发访问量变大的时候,怎么样做到横向扩展容器数量
这些容器管理的问题统称为容器编排问题,为了解决编排问题,就产生一些容器编排软件。其中最常见的就是k8s。
k8s的优点:
k8s组成部分,组件
一个K8s集群主要是由控制节点(master),工作节点(node)构成,每个节点会安排不同的组件。
master需要的的组件:
- Kublet: k8s的后端程序,用来启动对应容器。
- Apiserver是资源操作的唯一入口,接受用户输入的命令,提供认证授权等等。
- Scheduler:负责集群资源调度,按照调度策略,将pod调度到相应的node节点。
- ControllerManager: 负责维护集群的状态,比如程序部署安排,故障检测,自动扩展,滚动更新等。
- Etcd组件:负责存储集群中各种资源对象的信息,也是保证集群中信息的同步。
node需要的的组件
- 1 Kublet: 负责维护容器的生命周期,通过控制dokcer,创建,更新,销毁容器,相当于node节点的对接人,接受调度的命令。
- kubeProxy: 负责提供集群内部的服务发现和负载均衡。跟apiServer的区别,apiServer是控制入口,而kubeProxy可以访问pod中的容器。
- Dokcer 负责节点上容器的各种操作。
以部署一个nginx服务来说明k8s各个组建的调用关系。
k8s重要概念
Service跟apiServer不一样,Service是对外服务的统一入口,可以实现负载均衡,通过label堆pod进行分类,然后控制流量访问到哪个pod。
NameSpace,隔离pod,即不同NameSpace的pod无法互相访问。
集群搭建
使用kubeadm,这里使用三台虚拟机,自己配置ipv4地址。
环境搭建
- 2主机解析
具体其他操作可以观看https://www.cnblogs.com/weicunqi/p/14894122.html
当我们搭建好环境之后,可以启动一个ngxin试一下:
启动成功。
资源管理
在k8s中,一切皆资源。
* k8s是一个集群系统,用户可以在集群中部署各种服务,而部署服务就是在k8s集群中,运行一个一个容器。
- k8s最小单元是pod,pod也是一个资源,容器一般放在pod中,k8s不直接管理pod,而是通过 pod控制器(也是一资源),如Deployment, ReplicaSet等来管理pod
- pod在提供服务之后,提供了 Service 资源来访问pod中的服务,Service跟apiService是两码事。
学习k8s,就是要学习如何对集群上的pod, pod控制器,sService,存储等各种资源进行操作。
###资源管理方式
三种: - 命令时对象管理,直接操作k8s的资源。
kubectl run nginx-pod --image=nginx:1.17.1 --port=80
- 命令时对象配置,通过命令和配置文件,操作k8s资源,参数不再命令行写了,转到配置文件中了。
kubectl create/patch -f nginx-pod.yaml
- 声明式对象配置,通过apply和配置文件操作操作k8s资源。一般用于创建和更新资源。
kubectl apply -f nginx-pod.yaml
优缺点:
命令式对象管理
kubectl是kubernetes集群的命令行工具,通过它能够对集群本身进行管理,并能够在集群上进行容器化应用的安装部署。
kubectl [command] [type] [name] [flags]
kubectl get pod xxxx --namespace xxx
查看xxx命名空间内的xxx pod情况
comand:指定要对资源执行的操作,例如create、get、delete
type:指定资源类型,比如deployment、pod、service
name:指定资源的名称,名称大小写敏感
flags:指定额外的可选参数
资源类型
kubernetes中所有的内容都抽象为资源,可以通过下面的命令进行查看: kubectl api-resources
命令式配置对象管理
命令式对象配置就是使用命令配合配置文件一起来操作kubernetes资源。
命令式对象配置的方式操作资源,可以简单的认为:命令 + yaml配置文件(里面是命令需要的各种参数)
声明式对象配置
声明式对象配置就是使用apply描述一个资源最终的状态(在yaml中定义状态)
使用apply操作资源:
如果资源不存在,就创建,相当于 kubectl create
如果资源已存在,就更新,相当于 kubectl patch
总结
创建/更新资源 使用声明式对象配置 kubectl apply -f XXX.yaml
删除资源 使用命令式对象配置 kubectl delete -f XXX.yaml
查询资源 使用命令式对象管理 kubectl get(describe) 资源名称
YML语言
YAML是一个类似 XML、JSON 的标记性语言。它强调以数据为中心,并不是以标识语言为重点。因而YAML本身的定义比较简单,号称"一种人性化的数据格式语言"。
像.yml文件的编写等等都是用这种语法。
实战入门
Namespace
记住一点:Namespace可以将Pod隔离(跟label的区别),让其不可以互相访问。
不同组互相隔离,比如开发者看不到测试组。
[root@master ~]# kubectl get namespace
NAME STATUS AGE
default Active 45h # 所有未指定Namespace的对象都会被分配在default命名空间
kube-node-lease Active 45h # 集群节点之间的心跳维护,v1.13开始引入
kube-public Active 45h # 此命名空间下的资源可以被所有人访问(包括未认证用户)
kube-system Active 45h # 所有由Kubernetes系统创建的资源都处于这个命名空间
Pod
k8s的最小单元是pod,容器必须跑在pod,k8s通过pod控制器控制pod。
k8s在集群启动之后,各个组件也是通过pod的方式运行的。
corends,集群内通信。
etcd,存储对象资源。
apiserver,控制器入口。
controller-manage:决定pod在哪台运行。
scheduler,调度,
还有flannel网络,
以及proxy代理访问Pod等等。
一个Pod里面一般至少有两个容器,一个跟容器,不会计算在内。这个的意思 就是pod里面全部有一个容器,准备完毕的有1个。根容器不会计算在内。
kubectl run nginx --image=nginx:1.17.1 --port=80 --namespace dev
deployment.apps/nginx created
kubectl get deploy -n dev
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 2m15s
kubectl get pod -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-64777cd554-vvhdf 1/1 Running 0 3m4s 10.244.1.17 node1 <none> <none>
- 创建一个nginx的pod控制器,并且启动一个nginx服务,端口为80,namespace为dev
- -o wide表示详细删除,可以看到nginx服务器准备完成,并且抛在了node1服务器上。
- 这里查找的时候需要指定命名空间,因为不加就默认查找命名空间为default的
- curl 10.244.1.17:80就能在内部访问nginx,但是这个只是内部访问的,而且他是跟随pod的变化而变化的,也就是说当pod重建之后,ip就变了,所以就需要service提供一个稳定的ip进行访问。
- 删除pod不能直接删除pod,得直接删除pod控制器,否则pod控制器会当你删除pod的时候立马重启了一个pod。
label
- 在资源上添加标识,用他们来进行区分和选择。
- 如,一个网站的前台应用,和后台应用。我们想让他们分组,如果使用namespace的话,那么他们之间无法通信,显然不合常规,所以可以使用label来进行区分,分组(这也是跟namespace的本质区别)。
标签定义完毕之后,就需要选择标签。
Label Selector用于查询和筛选拥有某些标签的资源对象
pod控制器 Deployment
k8s中。pod是最小的控制单元,但是k8s不直接控制pod,而是通过一些pod控制器,如deployment,他会生成级联对象descrplate,由级联对象来控制pod.
- 当Pod资源出错的时候,pod控制器会尝试进行重启或者重建pod。
- deployment跟Pod的关系也是通过label来管理的
kubectl run nginx --image=nginx:1.17.1 --prot=80 --replicas=5 -n dev
[root@master ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-64777cd554-2hcgb 1/1 Running 0 10s 10.244.2.29 node2 <none> <none>
nginx-64777cd554-6btr6 1/1 Running 0 10s 10.244.2.28 node2 <none> <none>
nginx-64777cd554-dtbff 1/1 Running 0 10s 10.244.1.21 node1 <none> <none>
nginx-64777cd554-qpdcm 1/1 Running 0 10s 10.244.1.19 node1 <none> <none>
nginx-64777cd554-rwxbk 1/1 Running 0 10s 10.244.1.20 node1 <none> <none>
[root@master ~]# kubectl get pod -n dev --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx-64777cd554-2hcgb 1/1 Running 0 37s pod-template-hash=64777cd554,run=nginx
nginx-64777cd554-6btr6 1/1 Running 0 37s pod-template-hash=64777cd554,run=nginx
nginx-64777cd554-dtbff 1/1 Running 0 37s pod-template-hash=64777cd554,run=nginx
nginx-64777cd554-qpdcm 1/1 Running 0 37s pod-template-hash=64777cd554,run=nginx
nginx-64777cd554-rwxbk 1/1 Running 0 37s pod-template-hash=64777cd554,run=nginx
[root@master ~]#
- 可以看到,通过nginx的deploiyment管理器创建的pod,label都有一个run=nginx。
Service资源
- Pod创建完之后,我们需要对其访问,在集群内部可以通过pod ID来访问,但是pod ID不是固定不变的,如果pod出错重新创建了,那么pod Id就会变了。不固定。
- 这时候就需要通过service资源来访问,我们可以通过固定的Service Id来访问pod,service id是固定的,访问service id, server找到对应的pod访问。
[root@master ~]# kubectl get pods -n dev -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-64777cd554-22jzc 1/1 Running 0 9s 10.244.2.30 node2 <none> <none>
nginx-64777cd554-2dlfh 1/1 Running 0 9s 10.244.1.23 node1 <none> <none>
nginx-64777cd554-c9wmw 1/1 Running 0 9s 10.244.2.31 node2 <none> <none>
nginx-64777cd554-fbfpm 1/1 Running 0 9s 10.244.1.22 node1 <none> <none>
nginx-64777cd554-tx29r 1/1 Running 0 9s 10.244.1.24 node1 <none> <none>
[root@master ~]# kubectl get deploy -n dev -o wide
NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR
nginx 5/5 5 5 21s nginx nginx:1.17.1 run=nginx
pod在重建过程中,Pod IP是会改变的。并且集群外部无法访问Pod Ip
Service可以看作是一组同类pod对外的访问接口。
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx --type=ClusterIP --port=80 --target-port=80 -n dev
service/svc-nginx exposed
[root@master ~]# kubectl get service -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
svc-nginx ClusterIP 10.110.68.30 <none> 80/TCP 9s run=nginx
- 这里使用ClusterIp,仅在集群内访问service的ip
- 创建集群外访问的:
[root@master ~]# kubectl expose deploy nginx --name=svc-nginx --type=NodePort --port=80 --target-port=80 -n dev
service/svc-nginx exposed
[root@master ~]# kubectl get service -n dev -o wide
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
svc-nginx NodePort 10.109.27.97 <none> 80:30692/TCP 2s run=nginx
- NodePort表示创建集群外访问的service
访问成功。
更多推荐
所有评论(0)