kubernetes核心资源内容

这篇具有很好参考价值的文章主要介绍了kubernetes核心资源内容。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

参考连接:
https://blog.csdn.net/weixin_46703850/article/details/122922090

一、命名空间

1.命令行的方式创建命名命名空间

1.1 查看命名空间
kubectl get namespace 或者  kubectl get ns
1.2 查看所有名称空间的pods信息
kubectl get pods -A
1.3 查看指定命名空间的pod信息
kubectl get pods -n [namespace]
1.4 删除命名空间,会连带空间下的资源一期删除
kubectl delete ns [namespace]

2. yaml方式创建命名空间

2.1 创建命名空间yaml文件

文件名:createns.yaml

apiVersion: v1 # 版本
kind: Namespace # 类型
metadata:
  name: hello
2.2 应用(安装)yaml文件中的内容
$ kubectl apply -f createns.yaml

二、pod的使用

理解:
k8s将容器先封装成pod,再对pod进行操作,pod是kubernetes中应用的最小单位。
kubernetes核心资源内容
kubernetes核心资源内容

2. 命令行的方式,创建 并 运行pod

$ kubectl run 【Pod名称】 --image=【镜像名称】
2.1 创建并运行nginx pod容器
[root@k8s-mater ~]$ kubectl run mynginx --image=nginx
pod/mynginx created
2.2 查看 default命名空间的pod
[root@k8s-mater ~]$ kubectl get pod 
NAME      READY   STATUS    RESTARTS   AGE
mynginx   1/1     Running   0          2m23s
2.3 查看pod详细描述
$ kubectl describe pod 【Pod名称】
[root@k8s-mater ~]$ kubectl describe pod mynginx
Name:         mynginx
Namespace:    default # 所在名称空间
Priority:     0
Node:         node2/192.168.64.131 # 运行节点为node2
Start Time:   Fri, 11 Feb 2022 20:47:48 -0500
Labels:       run=mynginx
Annotations:  cni.projectcalico.org/containerID: 1385a3cd6d332c41ce6d538001af9044c091d76e54870cb1d13e5f69cb84ce80
              cni.projectcalico.org/podIP: 172.31.104.4/32
              cni.projectcalico.org/podIPs: 172.31.104.4/32
Status:       Running
IP:           172.31.104.4 # ip地址[每个Pod - k8s都会分配一个ip]
IPs:
  IP:  172.31.104.4
# ...

node2上执行 docker ps | grep mynginx 和 docker images | grep nginx 就能够查看nginx的镜像信息

2.4 查看pod的ip信息

注意:
(集群中的任意一个机器以及任意的应用都能通过Pod分配的ip来访问这个Pod)
此时的pod还不被外部访问

$ kubectl get pod -owide
[root@k8s-mater ~]$ kubectl get pod -o wide
NAME      READY   STATUS    RESTARTS   AGE     IP             NODE    NOMINATED NODE   READINESS GATES
mynginx   1/1     Running   0          7m27s   172.31.104.4   node2   <none>           <none>

访问容器id,返回nginx的欢迎页

[root@k8s-mater ~]$ curl 172.31.104.4
# ...
<h1>Welcome to nginx!</h1>
# ...
2.5 删除pod命令
$ kubectl delete pod 【Pod名称】
[root@k8s-mater ~]$ kubectl delete pod mynginx
pod "mynginx" deleted
2.6 查看pod运行日志命令
$ kubectl logs【Pod名称】

2. yaml方式创建pod

2.1 创建yaml文件

创建名称:creatpod.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: mynginx
  name: mynginx
  namespace: default # 设置命名空间 (可视化操作时设置命名空间 或 切换的特定命名空间再创建)
spec:
  containers:
  - image: nginx
    name: mynginx
2.2 应用yaml文件,创建pod
$ kubectl apply -f creatpod.yaml
2.3 应用yaml文件,删除pod
$ kubectl delete -f creatpod.yaml
2.4 进入pod(类似docker中进入容器)
$ kubectl exec -it mynginx -- /bin/bash
[root@k8s-mater Downloads]# kubectl exec -it mynginx -- /bin/bash
root@mynginx:/# ls
bin   dev                  docker-entrypoint.sh  home  lib64  mnt  proc  run   srv  tmp  var
boot  docker-entrypoint.d  etc                   lib   media  opt  root  sbin  sys  usr
root@mynginx:/# cd /usr/share/nginx/html
root@mynginx:/usr/share/nginx/html# ls
50x.html  index.html
root@mynginx:/usr/share/nginx/html# echo "Hello k8s" > index.html
root@mynginx:/usr/share/nginx/html# exit
exit
[root@k8s-mater Downloads]# curl 172.31.104.6
Hello k8s

2.5 实时监控pod数量保护

每1秒自动执行一次kubectl get pod

$ watch -n 1 kubectl get pod

3. 单个pod部署多个容器

创建名为:creatpods.yaml

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: myapp
  name: myapp
spec:
  containers:
  - image: nginx 		  # 容器1
    name: nginx  		 
  - image: tomcat:8.5.68   # 容器2
    name: tomcat           

$ kubectl apply -f creatpods.yaml
[root@k8s-mater Downloads]#  kubectl get pod
NAME      READY   STATUS              RESTARTS   AGE
myapp     0/2     ContainerCreating   0          14s
mynginx   1/1     Running             0          56m

测试访问

$ curl 172.31.166.132 		# 返回nginx的欢迎信息
$ curl 172.31.166.132:8080 	 # 返回tomcat的欢迎信息
注意

一个pod创建两个nginx容器的错误

apiVersion: v1
kind: Pod
metadata:
  labels:
    run: myapp2
  name: myapp2
spec:
  containers:
  - image: nginx 		 
    name: nginx01  		 
  - image: nginx 		 
    name: nginx02           

错误,因为nginx01占用了80端口,导致nginx02创建失败。

删除多个pod
$ kubectl delete myapp mynginx -n default

Deployment 部署

讲解:
Deployment可以控制pod,使pod拥有多个副本,自愈能力和扩缩容能力

普通创建运行的pod 是没有自愈能力的

$ kubectl run mynginx01 --image=nginx
[root@k8s-mater Downloads]# kubectl run mynginx01 --image=nginx
pod/mynginx01 created
[root@k8s-mater Downloads]# kubectl get pods 
NAME        READY   STATUS              RESTARTS   AGE
mynginx01   0/1     ContainerCreating   0          12s
[root@k8s-mater Downloads]# kubectl delete pods mynginx01
pod "mynginx01" deleted
[root@k8s-mater Downloads]# kubectl get pods 
No resources found in default namespace.

使用deployment创建pod 是拥有自愈能力

$ kubectl create deployment mynginx02 --image=nginx
[root@k8s-mater Downloads]# kubectl create deployment mynginx02 --image=nginx
deployment.apps/mynginx02 created
[root@k8s-mater Downloads]# kubectl get pods 
NAME                         READY   STATUS              RESTARTS   AGE
mynginx02-587cfb5b64-frmq9   0/1     ContainerCreating   0          6s
[root@k8s-mater Downloads]# kubectl delete pods mynginx02-587cfb5b64-frmq9 
pod "mynginx02-587cfb5b64-frmq9" deleted
[root@k8s-mater Downloads]# kubectl get pods 
NAME                         READY   STATUS              RESTARTS   AGE
mynginx02-587cfb5b64-w48z6   0/1     ContainerCreating   0          11s

可以看出,删除pod还是能够正常起来一个pod

删除拥有自愈能力的pod,方法是删除deployment部署

[root@k8s-mater Downloads]# kubectl get deployment 
NAME        READY   UP-TO-DATE   AVAILABLE   AGE
mynginx02   1/1     1            1           18m
[root@k8s-mater Downloads]# kubectl delete deployment mynginx02
deployment.apps "mynginx02" deleted
[root@k8s-mater Downloads]# kubectl get pods
No resources found in default namespace. # 删除成功

deployment部署多副本

通过命令行的方式使用deployment部署pod

假设部署三份

$ kubectl create deployment my-dep --image=nginx --replicas=3
[root@k8s-mater ~]# kubectl create deployment my-dep --image=nginx --replicas=3
deployment.apps/my-dep created
[root@k8s-mater ~]# kubectl get deployment
# 名称  可用/总数   正在更新   可用的pod数量
NAME     READY   UP-TO-DATE   AVAILABLE   AGE
my-dep   2/3     3            2           32s
[root@k8s-mater ~]# kubectl get pods 
NAME                      READY   STATUS    RESTARTS   AGE
my-dep-5b7868d854-4b2rb   1/1     Running   0          38s
my-dep-5b7868d854-ffr7k   1/1     Running   0          38s
my-dep-5b7868d854-v4w7j   1/1     Running   0          38s
kubectl get pods -owide #可以详细查看每个pod部署在哪个工作节点以及pod的ip等其他信息
[root@k8s-mater ~]# kubectl get pods -owide
NAME                        READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
my-dep-01-686cfb7bf-55p99   1/1     Running   0          38s   172.31.104.13    node2   <none>           <none>
my-dep-01-686cfb7bf-7qfvm   1/1     Running   0          38s   172.31.166.140   node1   <none>           <none>
my-dep-01-686cfb7bf-qvbz8   1/1     Running   0          38s   172.31.166.139   node1   <none>           <none>

通过yaml方式使用deployment来部署pod多个副本情况

创建名为:deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: my-dep-02
  name: my-dep-02
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-dep-02
  template:
    metadata:
      labels:
        app: my-dep-02
    spec:
      containers:
      - image: nginx
        name: nginx

通过 kubectl apply -f deployment.yaml 命令实现部署

扩缩容

扩容:如 原本只有node1和node2部署了mynginx(pod) ,扩容让node3和node4也部署了mynginx;

​ 缩容:如 原本只有node1和node2、node3、node4 部署了mynginx(pod) ,缩容让node3和node4不再部署mynginx。

​ 动态扩缩容:让k8s自己判断什么时候进行扩缩容

方法一:通过命令行直接扩缩容

扩容到5份

$ kubectl scale --replicas=5 deployment/my-dep-02

缩容到2分

$ kubectl scale --replicas=2 deployment/my-dep-02

方法二:通过编辑deployment配置文件,修改replicas字段并保存

注意:
通过这种方式更改,实际的配置文件是不会被修改的!
当然,也可以通过直接修改配置文件来修改副本数量,然后重新apply一下也能达到预期的效果

$ kubectl edit deployment my-dep-02

kubernetes核心资源内容
kubernetes核心资源内容

自愈和故障转移

自愈(其实前面有提到)

监控pods实时运行情况

$ watch -n 1 kubectl get pods -o wide
Every 1.0s: kubectl get pods -o wide                                                               Sat Feb 12 05:06:27 2022

NAME                         READY   STATUS    RESTARTS   AGE    IP               NODE    NOMINATED NODE   READINESS GATES
my-dep-02-7b9d6bb69c-6fvz7   1/1     Running   0          74m    172.31.166.144   node1   <none>           <none>
my-dep-02-7b9d6bb69c-dhjgr   1/1     Running   0          94m    172.31.104.16    node2   <none>           <none>
my-dep-02-7b9d6bb69c-hzs8f   1/1     Running   0          107m   172.31.104.15    node2   <none>           <none>

在node1中查看pods 对应的容器并暂停容器模拟故障

[root@node1 ~]# docker ps | grep my-dep-02-7b9d6bb69c-6fvz7
1a0f48f741dd   nginx                                                        "/docker-entrypoint.…"   About an hour ago   Up About an hour             k8s_nginx_my-dep-02-7b9d6bb69c-6fvz7_default_ae7938d7-cadc-439e-8d55-d25bde42431f_0
784bd86ee511   registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/pause:3.2   "/pause"                 About an hour ago   Up About an hour             k8s_POD_my-dep-02-7b9d6bb69c-6fvz7_default_ae7938d7-cadc-439e-8d55-d25bde42431f_0
[root@node1 ~]# docker stop 1a0f48f741dd

然后查看监控
kubernetes核心资源内容

但几秒后又恢复如初,并显示重启了一次
kubernetes核心资源内容

故障转移

直接关闭node1机器
kubernetes核心资源内容
n分钟后(排除是因为网络故障而导致的失联),发现pods在node2机器中重新建立
注意:这里转移时间比较长!

监控打印pods状态变化过程

$ kubectl get pods -w
[root@k8s-mater ~]# kubectl get pods -w
NAME                         READY   STATUS    RESTARTS   AGE
my-dep-02-7b9d6bb69c-6fvz7   1/1     Running   1          82m
my-dep-02-7b9d6bb69c-dhjgr   1/1     Running   0          102m
my-dep-02-7b9d6bb69c-hzs8f   1/1     Running   0          115m
my-dep-02-7b9d6bb69c-6fvz7   1/1     Terminating   1          86m

滚动更新

讲解:
将一个pod集群在正常提供服务时从V1版本升级成 V2版本

kubernetes核心资源内容

更新my-dep02的pod的镜像版本,–record表示记录更新

$ kubectl set image deployment/my-dep-02 nginx=nginx:1.16.1 --record
[root@k8s-mater ~]# kubectl set image deployment/my-dep-02 nginx=nginx:1.16.1 --record
deployment.apps/my-dep-02 image updated

​ 过程是不断启动新的pod,然后去除旧的(这个只能查看更新过程的情况没有实际作用)

$ kubectl rollout status deployment/my-dep-02

通过修改deployment配置文件实现更新(可以查看image位置的版本情况)

$ kubectl edit deployment/my-dep-02

版本回退

首先查看历史版本

$ kubectl rollout history deployment/my-dep-02

[root@k8s-mater ~]# kubectl rollout history deployment/my-dep-02
deployment.apps/my-dep-02 
REVISION  CHANGE-CAUSE
1         <none>
2         <none>
3         kubectl set image deployment/my-dep-02 nginx=nginx:1.16.1 --record=true

查看某个历史详情

$ kubectl rollout history deployment/my-dep-02 --revision=3

回滚到上一次的版本

$ kubectl rollout undo deployment/my-dep-02

回滚到指定的版本

$ kubectl rollout undo deployment/my-dep-02 --to-revision=1
[root@k8s-mater ~]# kubectl rollout undo deployment/my-dep-02 --to-revision=1
deployment.apps/my-dep-02 rolled back

查看deployment的配置文件来确定当前nginx的镜像版本

[root@k8s-mater ~]# kubectl get deployment/my-dep-02 -o yaml | grep image
                f:imagePullPolicy: {}
                f:image: {}
      - image: nginx
        imagePullPolicy: Always

工作负载(工作类型)

工作中使用工作负载操作pod,使pod具有更强大的功能。

​ 除了Deployment,k8s还有 StatefulSet 、DaemonSet 、Job 等 类型资源。我们都称为 工作负载。

有状态应用使用 StatefulSet 部署,无状态应用使用 Deployment 部署
kubernetes核心资源内容
例如:
有状态应用部署:如redis中的数据不能丢失,所以要采用有状态应用部署

服务网络

Service(服务)

​ (Service 缩写:svc)

​ 以上内容的pod中的容器我们在外网都无法访问,使用Service来解决(–type=NodePort)。

​ Service是 将一组 Pods 公开为网络服务的抽象方法。

kubernetes核心资源内容

pod的服务发现和负载均衡

负载均衡:请求分摊到多个 操作单元上(pod)进行执行;

​ 服务发现:服务发现是指使用一个注册中心来记录分布式系统中的全部服务的信息,以便其他服务能够快速的找到这些已注册的服务。

​ 服务发现示列:如果其中一个pod崩了Service也能及时发现,不将请求转发到该pod上,但pod恢复后,请求又可以转发到该pod。

修改3个pod中nginx容器的欢迎页

cd /usr/share/nginx/html;echo "nginx-01" > index.html
cd /usr/share/nginx/html;echo "nginx-02" > index.html
cd /usr/share/nginx/html;echo "nginx-03" > index.html

cat index.html

测试一下

[root@k8s-mater ~]# kubectl get pods -o wide
NAME                         READY   STATUS    RESTARTS   AGE    IP               NODE    NOMINATED NODE   READINESS GATES
my-dep-02-7b9d6bb69c-7cw2q   1/1     Running   0          108m   172.31.166.150   node1   <none>           <none>
my-dep-02-7b9d6bb69c-qgqrh   1/1     Running   0          109m   172.31.166.149   node1   <none>           <none>
my-dep-02-7b9d6bb69c-wjwkt   1/1     Running   0          108m   172.31.166.151   node1   <none>           <none>
[root@k8s-mater ~]# curl 172.31.166.150
nginx-02
[root@k8s-mater ~]# curl 172.31.166.149
nginx-03
[root@k8s-mater ~]# curl 172.31.166.151
nginx-01

命令行的方式暴露pod中的端口,并隐射(此时暴露映射出来的端口,还不能被外网访问)

暴露deployment的服务和端口,进行端口映射,创建出具有ip地址的Service (pod的集群)

$ kubectl expose deployment my-dep-02 --port=8000 --target-port=80

查看集群ip(集群ip的网段范围在 初始化主节点时的–service-cidr=10.96.0.0/16 配置了)

[root@k8s-mater ~]# kubectl get service
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP    26h
my-dep-02    ClusterIP   10.96.171.182   <none>        8000/TCP   5m59s

访问集群访问(负载均衡,分摊请求的压力),k8s集群内都可访问(包括启动pod内部),但外网不行。

[root@k8s-mater ~]# curl 10.96.171.182:8000
nginx-02 
[root@k8s-mater ~]# curl 10.96.171.182:8000
nginx-01
[root@k8s-mater ~]# curl 10.96.171.182:8000
nginx-03

查看pod标签

[root@k8s-mater ~]# kubectl get pod --show-labels
NAME                         READY   STATUS    RESTARTS   AGE    LABELS
my-dep-02-7b9d6bb69c-7cw2q   1/1     Running   0          126m   app=my-dep-02,pod-template-hash=7b9d6bb69c
my-dep-02-7b9d6bb69c-qgqrh   1/1     Running   0          126m   app=my-dep-02,pod-template-hash=7b9d6bb69c
my-dep-02-7b9d6bb69c-wjwkt   1/1     Running   0          126m   app=my-dep-02,pod-template-hash=7b9d6bb69c

使用标签检索pod
$ kubectl get pod -l app=my-dep-02

[root@k8s-mater ~]# kubectl get pod -l app=my-dep-02
NAME                         READY   STATUS    RESTARTS   AGE
my-dep-02-7b9d6bb69c-7cw2q   1/1     Running   0          112m
my-dep-02-7b9d6bb69c-qgqrh   1/1     Running   0          113m
my-dep-02-7b9d6bb69c-wjwkt   1/1     Running   0          112m

查看service/my-dep-02 的yaml配置文件

$ kubectl get service/my-dep-02 -o yaml

显示的内容

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2022-02-12T12:55:38Z"
  labels:
    app: my-dep-02
  # ...
spec:
  clusterIP: 10.96.171.182
  clusterIPs:
  - 10.96.171.182
  ports:
  - port: 8000
    protocol: TCP
    targetPort: 80
  selector:
    app: my-dep-02
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}

在pod内部域名访问Service集群

​域名构成规则: 服务名.名称空间.svc

​ 如:my-dep-02.default.svc

新建pod进行测试

root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02.default.svc:8000
nginx-03
root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02.default.svc:8000
nginx-02
root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02.default.svc:8000
nginx-03
root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02.default.svc:8000
nginx-01

这里测试 curl my-dep-02:8000也可以(因为默认default,不加也行,要是别的空间,就必须跟上了)

root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02:8000
nginx-03
root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02:8000
nginx-02
root@my-tomcat-5987455b6b-npkr6:/usr/local/tomcat# curl my-dep-02:8000
nginx-02

删除service

$ kubectl delete  service my-dep-02

讲解ClusterIP和NodePort

ClusterIP:集群ip,集群内访问

默认就是ClusterIP 等同于没有–type的

$ kubectl expose deployment my-dep-02 --port=8000 --target-port=80 --type=ClusterIP #所以加与不加都是ClusterIP 
NodePort 集群外可以访问
$ kubectl expose deployment my-dep-02 --port=8000 --target-port=80 --type=NodePort #要想在集群外部,就可以通过宿主机ip加暴露的端口访问pod里面的服务

查看服务

[root@k8s-mater ~]# kubectl get service
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
kubernetes   ClusterIP   10.96.0.1       <none>        443/TCP          38h
my-dep-02    NodePort    10.96.241.166   <none>        8000:30670/TCP   57m

每个部署pod的机器都会开30670端口(NodePort范围在 30000-32767 之间)

集群内访问

现在是通过serviceip+service暴露的端口访问

[root@k8s-mater ~]# curl  10.96.241.166:8000
nginx-02
[root@k8s-mater ~]# curl  10.96.241.166:8000
nginx-01
[root@k8s-mater ~]# curl  10.96.241.166:8000
nginx-01
[root@k8s-mater ~]# curl  10.96.241.166:8000
nginx-03

集群外访问

现在是通过宿主机ip+NodePort暴露的端口访问
ip+port映射: 集群外(mater、node1、node2的ip):30670 映射到 10.96.241.166:8000

​ 如外网访问 http://192.168.64.128:30670/
kubernetes核心资源内容

kubernetes核心资源内容

ingress(通过域名方式访问)

官网地址:https://kubernetes.github.io/ingress-nginx/

安装Ingress

​ Ingress:Service的统一网关入口(如百度的统一域名访问,统一Service层),Ingress是k8s机器集群的统一入口,请求流量先经过Ingress(入口)再进入集群内接受服务。

​ service是为一组pod服务提供一个统一集群内访问入口或外部访问的随机端口,而ingress做得是通过反射的形式对服务进行分发到对应的service上。

​ service一般是针对内部的,集群内部调用,而ingress应该是针对外部调用的

​ service只是开了端口,可以通过服务器IP:端口的方式去访问,但是服务器IP还是可变的,Ingress应该就是作为网关去转发

因为有很多服务,入口不统一,不方便管理

​ ingress rule相当于定义了路由规则,通过ingress controlle动态将各路由规则写到第三方的load balancer(比如nginx)

​ 具体有第三方的load balancer做路由转发到对应的pods,ingress主要是实现动态将路由规则写到第三方的load balancer

kubernetes核心资源内容

首先安装我们的ingress

下载ingress的yaml文件用于安装到k8s中

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.47.0/deploy/static/provider/baremetal/deploy.yaml

如果下载不了可以使用下面一个人yaml信息

ingress的yaml文件下载路径

下载好后应用 deploy.yaml

$ kubectl apply -f deploy.yaml

查看安装结果

$ kubectl get pod,svc -n ingress-nginx

查看安装情况

[root@k8s-mater Downloads]# kubectl get pod -A | grep ingress
ingress-nginx          ingress-nginx-admission-create-nnx47         0/1     Completed           0          68s
ingress-nginx          ingress-nginx-admission-patch-r9xxb          0/1     Completed           0          68s
ingress-nginx          ingress-nginx-controller-65bf56f7fc-njsmd    0/1     ContainerCreating   0          68s

[root@k8s-mater ~]# kubectl get service -A | grep ingress
ingress-nginx          ingress-nginx-controller             NodePort    10.96.105.233   <none>        80:30813/TCP,443:31761/TCP   27m
ingress-nginx          ingress-nginx-controller-admission   ClusterIP   10.96.129.25    <none>        443/TCP                      27m

测试访问一下我们安装并暴露的ingress服务
访问 服务器ip:30813 和 服务器ip:31761

​ 映射:80:30813/TCP,443:31761/TCP

​ 所有的服务器都开放了30813和31761的端口

端口30813 用于处理http请 (http的TCP端口是80)
kubernetes核心资源内容
端口31761用于处理https请求(https的TCP端口是443)

kubernetes核心资源内容

部署一个测试环境,检测ingress

注意:​ Ingress就是用nginx作的

kubernetes核心资源内容
测试的yaml文件在这里

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: hello-server
  template:
    metadata:
      labels:
        app: hello-server
    spec:
      containers:
      - name: hello-server
        image: registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/hello-server
        ports:
        - containerPort: 9000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-demo
  name: nginx-demo
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo
  template:
    metadata:
      labels:
        app: nginx-demo
    spec:
      containers:
      - image: nginx
        name: nginx
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-demo
  name: nginx-demo
spec:
  type: NodePort
  selector:
    app: nginx-demo
  ports:
  - port: 8000
    protocol: TCP
    targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: hello-server
  name: hello-server
spec:
  type: NodePort
  selector:
    app: hello-server
  ports:
  - port: 8000
    protocol: TCP
    targetPort: 9000

测试的yaml文件名称为:ingresstest.yaml
应用配置文件,部署了2个Deployment,2个Service

$ kubectl apply -f Ingresstest.yaml

查看service情况

[root@k8s-mater Downloads]# kubectl get service
NAME           TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
hello-server   ClusterIP   10.96.61.143    <none>        8000/TCP         2m48s
nginx-demo     ClusterIP   10.96.252.133   <none>        8000/TCP         2m48s
# ...

[root@k8s-mater Downloads]# curl 10.96.61.143:8000
Hello World!
[root@k8s-mater Downloads]# curl 10.96.252.133
# ...
<h1>Welcome to nginx!</h1>
# ...

查看deployment

[root@k8s-mater Downloads]# kubectl get deployment -o wide
NAME           READY   UP-TO-DATE   AVAILABLE   AGE     CONTAINERS     IMAGES          SELECTOR             
hello-server   2/2     2            2           3m47s   hello-server   registry.cn***   app=hello-server
nginx-demo     2/2     2            2           3m47s   nginx          nginx           app=nginx-demo

查看pod

[root@k8s-mater Downloads]# kubectl get pods -o wide
NAME                            READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
hello-server-6cbb679d85-pf7jx   1/1     Running   0          13m   172.31.166.158   node1   <none>           <none>
hello-server-6cbb679d85-z7b65   1/1     Running   0          13m   172.31.166.159   node1   <none>           <none>

nginx-demo-7d56b74b84-2xjh4     1/1     Running   0          13m   172.31.166.160   node1   <none>           <none>
nginx-demo-7d56b74b84-hskdx     1/1     Running   0          13m   172.31.104.24    node2   <none>           <none>

设置指定的域名来访问你的service

目标

访问 hello.test.com 的请求由 hello-server (Service)集群处理
访问 demo.test.com 的请求由 nginx-demo (Service)集群处理
Ingress(网关)根据请求的域名分配对应的Service去处理

配置文件:ingresscom.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress  # 类型
metadata:
  name: ingress-host-bar
spec:
  ingressClassName: nginx
  rules:
  - host: "hello.test.com" #域名
    http:
      paths:
      - pathType: Prefix # 前缀
        path: "/"
        backend:
          service:
            name: hello-server # Service 名称
            port:
              number: 8000 # 端口
  - host: "demo.test.com"
    http:
      paths:
      - pathType: Prefix
        path: "/nginx"  # 把请求会转给下面的service,下面的service一定要能处理这个路径,不能处理就是404
        backend:
          service:
            name: nginx-demo  # java,比如使用路径重写,去掉前缀nginx
            port:
              number: 8000

应用配置文件

$ kubectl apply -f ingresscom.yaml
[root@k8s-mater Downloads]# kubectl apply -f ingresscom.yaml
ingress.networking.k8s.io/ingress-host-bar created

查看刚才应用ingresscom文件后生成网关(ingress)

[root@k8s-mater Downloads]# kubectl get ingress
NAME               CLASS   HOSTS                          ADDRESS          PORTS   AGE
ingress-host-bar   nginx   hello.test.com,demo.test.com   192.168.64.130   80      30s

最后,在你的windwos中配置域名映射(域名映射文件地址:C:\Windows\System32\drivers\etc)

192.168.64.128 hello.test.com 
192.168.64.128 demo.test.com 

访问测试
访问 http://hello.test.com:30813/

kubernetes核心资源内容
访问 https://demo.test.com:31761/ ,nginx是由Ingress层返回的
kubernetes核心资源内容
访问 https://demo.test.com:31761/nginx ,nginx是由nginx-demo中的pod返回的
kubernetes核心资源内容
修改Ingress配置文件,将path: "/nginx"改成path: “/nginx.html”

$ kubectl edit ingress ingress-host-bar

进入nginx-demo中的pod的nginx容器内修改nginx文件
kubectl exec -it podname – /bin/bash

cd /usr/share/nginx/html;echo "<h1>Hello nginx2</h1>" > nginx.html;ls

kubernetes核心资源内容

总结ingress实现

  1. 安装ingress.yaml
  2. 应用这个ingress.yaml,默认生成3个pod,一个service(默认80端口)并暴露两个端口(http和https)
  3. 编写测试ingresstest.yaml文件,应用并生成两个deployment和两个service以及4个pod
  4. 编写域名ingresscom.yaml文件,通过两个域名文件来指向service的name和端口并应用
  5. 然后通过本地windows电脑来映射你的目标ip+域名就可以访问啦

路径重写

路径重写的环境搭建

修改配置文件 Ingresscom.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress  
metadata:
  annotations: # 路径重写配置功能开启
    nginx.ingress.kubernetes.io/rewrite-target: /$2 
  name: ingress-host-bar
spec:
  ingressClassName: nginx #这个位置为nginx,最好不要修改
  rules:
  - host: "hello.test.com"
    http:
      paths:
      - pathType: Prefix
        path: "/"
        backend:
          service:
            name: hello-server
            port:
              number: 8000
  - host: "demo.test.com"
    http:
      paths:
      - pathType: Prefix
        path: "/nginx(/|$)(.*)"  # 配置忽略/nginx
        backend:
          service:
            name: nginx-demo 
            port:
              number: 8000

重新应用

$ kubectl apply -f Ingresscom.yaml
[root@k8s-mater Downloads]# kubectl apply -f Ingresscom.yaml
ingress.networking.k8s.io/ingress-host-bar configured

效果:

访问 https://demo.test.com:31761/nginx 相当于访问 https://demo.test.com:31761/

kubernetes核心资源内容

访问 https://demo.test.com:31761/nginx/ 也相当于访问 https://demo.test.com:31761/
访问 https://demo.test.com:31761/nginx/nginx.html 相当于访问 https://demo.test.com:31761/nginx.html
kubernetes核心资源内容

存储抽象

​ docker有目录挂载的功能,但直接挂载,挂载目录繁多,难以管理,同时一旦发生故障转移,转移后的pod在容器挂载目录在

转移后的主机上不存在。

​ k8s的解决方案是,将服务器用于挂载目录组成存储层,存储层中的挂载目录由k8s统一管理,存储层使用技术可自定义(Glusterfs,NFS,CephFS等)。

kubernetes核心资源内容

存储层技术

NFS技术:每个服务器都备份

kubernetes核心资源内容

搭建NFS网络文件系统环境

kubernetes核心资源内容
所有服务器(节点)安装NFS工具

yum install -y nfs-utils

主节点(mater)操作
暴露目录,开发权限

echo "/nfs/data/ *(insecure,rw,sync,no_root_squash)" > /etc/exports

创建目录

mkdir -p /nfs/data

启动rpc远程绑定

systemctl enable rpcbind --now 

使配置生效

exportfs -r

查看配置

[root@k8s-mater ~]# exportfs
/nfs/data       <world>

在安装nfs的服务器中,都要启动nfs服务

sudo systemctl start  nfs-server
sudo systemctl enable nfs-server
sudo systemctl status nfs-server

从节点(node1、node2)操作
显示可用挂载点 showmount -e 主节点ip

showmount -e 192.168.64.128

如果是外网服务器的,不能查看到信息或则超时的,需要控制台打开端口
kubernetes核心资源内容

[root@node1 ~]# showmount -e 192.168.64.128
Export list for 192.168.64.128:
/nfs/data *

创建目录

在你的工作节点
mkdir -p /nfs/data

挂载 (执行以下命令挂载 nfs 服务器上的共享目录到本机路径 /nfs/data)

在你的工作节点执行,你要挂载的哪个nfs服务器(maste节点)的那个目录
mount -t nfs 192.168.64.128:/nfs/data /nfs/data

写入一个测试文件,>是覆盖写, >> 是追加

在工作节点执行,执行后,(master节点)192.168.64.128:/nfs/data 目录也会有这个文件
echo "hello nfs server" > /nfs/data/test.txt

如果想让其他工作节点也有这个测试文件,需要你在指定的工作节点上进行挂载((master)192.168.64.128:/nfs/data)目录

mount -t nfs 192.168.64.128:/nfs/data /nfs/data

问题:
如果(master)192.168.64.128:/nfs/data 服务器宕机,是否无法进行挂载!!!
答:整个nfs挂载环境不能用,所以nfs要进行高可用部署

cat /nfs/data/test.txt

NFS(原生)方式数据挂载(配置文件方式,使pod直接挂载指定目录)

创建目录

mkdir /nfs/data/nginx-pv/

因为是挂载目录关系,只需要在master下或则其中一个工作节点中创建就能能实现所有挂载目录的创建

配置文件 mountnfs.yaml

容器路径 /usr/share/nginx/html 映射到 服务器路径 /nfs/data/nginx-pv

​ 2个pod挂载同一路径

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-pv-demo
  name: nginx-pv-demo
spec:
  replicas: 2 
  selector:
    matchLabels:
      app: nginx-pv-demo
  template:
    metadata:
      labels:
        app: nginx-pv-demo
    spec:
      containers:
      - image: nginx
        name: nginx
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html
      volumes:
        - name: html
          nfs:
            server: 192.168.64.128
            path: /nfs/data/nginx-pv/

应用配置文件

$ kubectl apply -f mountnfs.yaml

测试,挂载成功

[root@k8s-mater Downloads]# cd /nfs/data/nginx-pv/
[root@k8s-mater nginx-pv]# echo "Hello Mount" > index.html

root@nginx-pv-demo-fc6c6dd8d-smhzx:/# cd /usr/share/nginx/html
root@nginx-pv-demo-fc6c6dd8d-smhzx:/usr/share/nginx/html# ls
index.html
root@nginx-pv-demo-fc6c6dd8d-smhzx:/usr/share/nginx/html# cat index.html
Hello Mount

[root@k8s-mater nginx-pv]# kubectl get pods -o wide
NAME                            READY   STATUS    RESTARTS   AGE     IP               NODE    NOMINATED NODE   READINESS GATES
nginx-pv-demo-fc6c6dd8d-smhzx   1/1     Running   0          4m27s   172.31.166.166   node1   <none>           <none>
nginx-pv-demo-fc6c6dd8d-vnwdc   1/1     Running   0          4m27s   172.31.166.165   node1   <none>           <none>
[root@k8s-mater nginx-pv]# curl 172.31.166.166
Hello Mount

PV(持久卷)和PVC(持久卷申明)

注意:使用pv是需要nfs的!!!
1.首先要确保已经安装好了yum install -y nfs-utils rpcbind
2.要确定要本地挂载的目录
3.在/etc/exports文件中添加你要挂载的本地目录权限
如:
/nfs/data/ *(insecure,rw,sync,no_root_squash)
/pvcnfs/ *(insecure,rw,sync,no_root_squash)
执行一下(刷新配置,使之生效):
#exportfs -rv
执行一下:
查看本机发布的共享目录
#showmount -e
4.手动加载 NFS 共享服务时,应该先启动 rpcbind,再启动 nfs
systemctl start rpcbind && systemctl enable rpcbind
systemctl start nfs && systemctl enable nfs
5.查看 rpcbind 端口是否开启,rpcbind 服务默认使用 tcp 端口 111
netstat -anpt | grep rpcbind
6.pv.yaml中
storageClassName: nfs # 存储类名可自定义

然后就可以被pv挂载使用啦!

NFS(原生)方式数据挂载存在一些问题:

目录要自己创建
Deployment及其pod删除后,服务器目录数据依旧存在
挂载容量没有限制.

PV:持久卷(Persistent Volume),将应用需要持久化的数据保存到指定位置(存放持久化数据的目录就是持久卷)

​ PVC:持久卷申明(Persistent Volume Claim),申明需要使用的持久卷规格 (申请持久卷的申请书)

静态供应: 提取指定位置和空间大小

动态供应:位置和空间大小由pv自动创建

创建PV(持久卷)

创建pv池
nfs主节点(mater)操作

mkdir -p /nfs/data/01
mkdir -p /nfs/data/02
mkdir -p /nfs/data/03

创建三个 PV(持久卷)静态供应的方式,配置文件createPV.yaml

apiVersion: v1
kind: PersistentVolume # 类型
metadata:
  name: pv01-10m # 名称
spec:
  capacity:
    storage: 10M # 持久卷空间大小
  accessModes:
    - ReadWriteMany # 多节点可读可写
  storageClassName: nfs # 存储类名
  nfs:
    path: /nfs/data/01 # pc目录位置
    server: 192.168.64.128
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv02-1gi
spec:
  capacity:
    storage: 1Gi # 持久卷空间大小
  accessModes:
    - ReadWriteMany
  storageClassName: nfs
  nfs:
    path: /nfs/data/02 # pc目录位置
    server: 192.168.64.128
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv03-3gi
spec:
  capacity:
    storage: 3Gi # 持久卷空间大小
  accessModes:
    - ReadWriteMany
  storageClassName: nfs
  nfs:
    path: /nfs/data/03 # pc目录位置
    server: 192.168.64.128

应用

[root@k8s-mater Downloads]# kubectl apply -f createPV.yaml
persistentvolume/pv01-10m created
persistentvolume/pv02-1gi created
persistentvolume/pv03-3gi created

查看PV

[root@k8s-mater Downloads]# kubectl get persistentvolume
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
pv01-10m   10M        RWX            Retain           Available           nfs                     26s
pv02-1gi   1Gi        RWX            Retain           Available           nfs                     26s
pv03-3gi   3Gi        RWX            Retain           Available           nfs                     26s

PVC(持久卷申明)创建与绑定到自适应的PV卷中

创建PVC
createPVC.yaml

kind: PersistentVolumeClaim # 类型
apiVersion: v1
metadata:
  name: nginx-pvc # PVC名称
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 200Mi # 需要空间,它会更具定义的大小自动去找与之匹配的PV卷
  storageClassName: nfs # 要对应PV的存储类名称storageClassName

应用

[root@k8s-mater Downloads]# kubectl apply -f createPVC.yaml
persistentvolumeclaim/nginx-pvc created

查看PVC,挂载 pv02-1gi,挂载目录为 /nfs/data/02

[root@k8s-mater Downloads]# kubectl get persistentvolumeclaim
NAME        STATUS   VOLUME     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
nginx-pvc   Bound    pv02-1gi   1Gi        RWX            nfs            17s

查看PC,状态Bound(绑定),说明已经被使用,绑定信息: default/nginx-pvc => 名称空间/PVC名称(绑定空间选择最小且大小足够的)

[root@k8s-mater Downloads]# kubectl get pv
NAME       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM               STORAGECLASS   REASON   AGE
pv01-10m   10M        RWX            Retain           Available                       nfs                     14m
# 状态Bound(绑定)
pv02-1gi   1Gi        RWX            Retain           Bound       default/nginx-pvc   nfs                     14m
pv03-3gi   3Gi        RWX            Retain           Available                       nfs                     14m

创建Deployment ,让Deployment中的Pod绑定PVC

配置文件 boundPVC.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-deploy-pvc # Deployment名称
  name: nginx-deploy-pvc
spec:
  replicas: 2 # pod数量
  selector:
    matchLabels:
      app: nginx-deploy-pvc
  template:
    metadata:
      labels:
        app: nginx-deploy-pvc
    spec:
      containers:
      - image: nginx
        name: nginx
        volumeMounts:
        - name: html
          mountPath: /usr/share/nginx/html # 挂载目录
      volumes:
        - name: html
          persistentVolumeClaim:
            claimName: nginx-pvc  # pvc 的名称

应用

[root@k8s-mater Downloads]# kubectl apply -f boundPVC.yaml
deployment.apps/nginx-deploy-pvc created

测试
向挂载目录 /nfs/data/02写入测试文件

[root@k8s-mater Downloads]# cd /nfs/data/02
[root@k8s-mater 02]# echo "boundPVC test nginx" > index.html

访问成功

[root@k8s-mater 02]# kubectl get pod -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE    NOMINATED NODE   READINESS GATES
nginx-deploy-pvc-79fc8558c7-26grh   1/1     Running   0          15m   172.31.166.168   node1   <none>           <none>
nginx-deploy-pvc-79fc8558c7-2gz4d   1/1     Running   0          15m   172.31.166.169   node1   <none>           <none>
[root@k8s-mater 02]# curl 172.31.166.168
boundPVC test nginx

总结下这个PV&PVC

  1. 首先要明白PV是持久卷(实际存在的),PVC是去申明我要PV卷;
  2. 创建三个指定目录,然后通过PV.yaml去绑定,里面编写多个PVC卷来指定不同的空间大小和绑定的实际目录,然后应用;
  3. 编写PVC.yaml,设定需要的大小和存储卷名称,然后应用,会根据你的大小来自动分配PV卷;
  4. 编写一个测试的deployment.yaml文件,指定绑定的PVC卷,然后应用;
  5. 测试一下,得知PVC所绑定的PV卷目录后,到目录中创建index.html文件,然后通过curl+podip访问。

kubernetes核心资源内容

ConfigMap(配置集)

ConfigMap 缩写为cm

ConfigMap(配置集):用于配置文件挂载,抽取应用配置,并且可以自动更新。

以redis为示例

创建 redis.conf

appendonly yes

把之前的配置文件创建为配置集
创建配置,redis保存到 k8s的etcd(k8s资料库)

$ kubectl create configmap redis-conf --from-file=redis.conf
[root@k8s-mater Downloads]# kubectl create configmap redis-conf --from-file=redis.conf
configmap/redis-conf created

查看ConfigMap(配置集)

[root@k8s-mater Downloads]# kubectl get configmap
NAME               DATA   AGE
kube-root-ca.crt   1      2d14h
redis-conf         1      31s

查看 redis-conf(配置集)的配置文件

 $ kubectl get configmap redis-conf -o yaml
在这里插入代码片

kubernetes核心资源内容

[root@k8s-mater Downloads]#
apiVersion: v1
data: # data是所有真正的数据,key:默认是文件名   value:配置文件的内容
  redis.conf: |
    appendonly yes
kind: ConfigMap # 类型
metadata:
  #  ...
  name: redis-conf
  namespace: default
  # ...

创建pod
​ 配置文件 cm01.yaml

apiVersion: v1
kind: Pod # 类型
metadata:
  name: redis # pod名称
spec:
  containers:
  - name: redis
    image: redis # 镜像
    command:
      - redis-server
      - "/redis-master/redis.conf"  #指的是redis容器内部的位置
    ports:
    - containerPort: 6379 
    volumeMounts: # 配置卷挂载
    - mountPath: /data 
      name: data 	# 卷挂载名称  对应 下面的 挂载卷 data
    - mountPath: /redis-master
      name: config	 # 卷挂载名称  对应 下面的 挂载卷 config
  volumes: # 挂载卷
    - name: data 
      emptyDir: {} #在 Pod 启动时创建,容器可以读写该目录中的文件。当 Pod 从节点中删除时,该目录和其中的数据也将被删除
    - name: config #与上面挂载的对应
      configMap:   # 配置集
        name: redis-conf #要对应confimap的名称
        items:
        - key: redis.conf #这个是redis-conf中key名称,来挂载所对应的值到指定path文件中
          path: redis.conf #这对应的是容器内要挂载的哪个文件名称

​ /redis-master 路径 挂载了 配置集 redis.conf

应用

$ kubectl apply -f cm01.yaml

检查默认配置

root@redis:/data# cat /redis-master/redis.conf
appendonly yes

修改 配置集redis.conf 的配置数据,增加 requirepass 123456

$ kubectl edit configmap redis-conf 

检查配置是否更新,修改了cm,Pod里面的配置文件会跟着改变

root@redis:/data# cat /redis-master/redis.conf
appendonly yes
requirepass 123456

如果配置值未更改,因为需要重新启动 Pod 才能从关联的 ConfigMap 中获取更新的值。

​ 原因:我们的Pod部署的中间件自己本身没有热更新能力

9、 进入pod内的Redis,查看配置

$ kubectl exec -it redis -- redis-cli
127.0.0.1:6379> CONFIG GET appendonly
"appendonly"
"yes"
127.0.0.1:6379> CONFIG GET requirepass
"requirepass"
""

另外,创建configmap可以使用yaml方式,更方便
config-map-redis.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: redis-config
data:
  redis-config: |+
    requirepass 123456

正常应用到k8s中就好:kubectl apply -f config-map-redis.yaml
kubernetes核心资源内容文章来源地址https://www.toymoban.com/news/detail-451789.html

到了这里,关于kubernetes核心资源内容的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • Kubernetes核心概念汇总—Kubernetes 架构

    目录 ​编辑 一、概述 1、时光回溯 2、为什么需要 Kubernetes,它能做什么? 3、Kubernetes 不是什么  二、Kubernetes 架构  1、节点 2、管理 节点名称唯一性 节点自注册 手动节点管理 3、节点状态 地址 状况 容量(Capacity)与可分配(Allocatable) 信息(Info) 4、心跳 5、节点控制器

    2024年02月11日
    浏览(47)
  • 【云原生、Kubernetes】Kubernetes核心概念理解

    首先我们要掌握 Kubernete 的一些核心概念。 这些核心可以帮助我们更好的理解 Kubernetes 的特性和工作机制。 首先,Kubernetes 集群中包含2类节点,分别是:master控制节点和node工作节点。 master 控制节点 负责管理整个集群系统,可以说它是集群的网关和中枢,是Kubernetes 的大脑和

    2024年02月13日
    浏览(42)
  • Kubernetes技术--Kubernetes架构组件以及核心概念

    1. Kubernetes集群架构组件   搭建一个 Kubernetes环境集群,其架构如下所示: 内容详解: Master : 控制节点,指派任务、决策 Node : 工作节点,实际干活的。 Master组件内容:

    2024年02月10日
    浏览(51)
  • 【云原生 • Kubernetes】kubernetes 核心技术 - Service

    1. Service 的定义 Service 是 Kubernetes 的核心概念之一,创建一个 Service 可以为一组具有相同功能的容器应用提供一个统一的入口地址,并且将请求负载分发到后端的各个容器应用上。 完整 yaml 格式的 Service 定义文件如下: 2. Service 的基本用法 一般情况下,对外部提供服务的应用

    2024年02月01日
    浏览(39)
  • 【kubernetes系列】Kubernetes之资源限制ResourceQuota

    当多个用户或团队共享具有固定节点数目的集群时,人们会担心有人使用超过其基于公平原则所分配到的资源量。我们可以通过ResourceQuota来解决这个问题,对每个namespace的资源消耗总量提供限制。它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命名空间中的

    2024年02月16日
    浏览(44)
  • 【kubernetes系列】kubernetes之计算资源管理

    在 Kubernetes 中,Node 提供资源,而 Pod 使用资源。其中资源分为计算(CPU、Memory、GPU)、存储(Disk、SSD)、网络(Network Bandwidth、IP、Ports)。这些资源提供了应用运行的基础,正确理解这些资源以及集群调度如何使用这些资源,对于大规模的 Kubernetes 集群来说至关重要,不仅

    2024年02月17日
    浏览(45)
  • 《云计算实践与原理》考试内容及参考答案

    1 、分布式存储: 是数据存储技术。它通过网络使用企业中每台机器的磁盘空间。这些分散的存储资源构成了虚拟存储设备,数据分布在企业的各个角落。分布式存储系统,它可以在多个独立的设备上分布数据。传统的网络存储系统采用集中式存储服务器来存储所有数据。存

    2024年02月09日
    浏览(52)
  • kubernetes核心组件

    目录 前言 一、Kubernetes的核心组件 1、Master组件 1.1 kube-api server 1.2 Kube-controller-manager 1.3 kube-scheduler 1.4 配置存储中心 — etcd 1.5 主节点工作流程 2、Node 组件 2.1 Kubelet 2.2 Kube-Proxy 2.3 docker 或 rocket 二、Kubernetes核心概念  1、Pod 2、Pod 控制器 2.1 Deployment—无状态应用部署 2.2 Statefu

    2023年04月17日
    浏览(40)
  • kubernetes核心概念 controller

    controller用于控制pod 参考: https://kubernetes.io/zh/docs/concepts/workloads/controllers/ 控制器主要分为: Deployments 部署无状态应用,控制pod升级,回退 ReplicaSet 副本集,控制pod扩容,裁减 ReplicationController(相当于ReplicaSet的老版本,现在建议使用Deployments加ReplicaSet替代RC) StatefulSets 部署有状态应用

    2024年02月11日
    浏览(48)
  • 6、Kubernetes核心技术 - Pod

    目录 一、概述 二、Pod机制 2.1、共享网络 2.2、共享存储 三、Pod资源清单 四、 Pod 的分类 五、Pod阶段 六、Pod 镜像拉取策略 ImagePullBackOff 七、Pod 资源限制 八、容器重启策略 Pod 是可以在 Kubernetes 中 创建和管理的、最小的可部署的计算单元 。Pod 里面是由一个或多个容器组成

    2024年02月15日
    浏览(72)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包