Kubernetes-3

news/2024/6/3 17:22:04 标签: kubernetes, 容器, 云原生, shell

Kubernetes学习第3天

  • Kubernetes-3
    • 1、查看实时的cpu和内存消耗
      • 1.1、kubectl top node
    • 2、卷的使用
      • 2.1、什么是卷?
        • 1. 解决数据持久性问题
        • 2. Kubernetes 中的卷抽象概念
        • 3. 共享数据示例
        • 4. Kubernetes 中的卷使用
        • 5. 不同类型的卷
        • 6. 灵活、可靠的数据管理
      • 2.2、联想到docker中的卷
      • 2.3、实践一下
    • 3、一个pod里启多个容器--容器类型
      • 3.1、写个简单的yaml文件
      • 3.2、运行yaml文件
      • 3.3、可不可以在yaml中同时创建pod和命名空间
      • 3.4、进入pod中的容器
      • 3.5、多个软件配合互相共享资源-sidecar
      • 3.6、利用边车模式去写个yaml,对日志的记录
      • 3.7、进一步做边车实验
    • 4、容器类型
    • 5、服务发现
    • 6、小练习

Kubernetes-3

1、查看实时的cpu和内存消耗

1.1、kubectl top node

首先要装个软件:metrics-server----》可获取pod的cpu,内存使用情况

  1. 在外界下载下:metrics-server的yaml文件,然后上传到虚拟机,进行解压

    shell">[root@master pod]# unzip metrics-server.zip 
    [root@master pod]# 
    
  2. 进入metrics-server文件夹,把tar包传递给node节点

    shell">[root@master metrics-server]# ls
      components.yaml  metrics-server-v0.6.3.tar
    [root@master metrics-server]# scp metrics-server-v0.6.3.tar node-1:/root
    metrics-server-v0.6.3.tar                             100%   67MB 150.8MB/s   00:00    
    [root@master metrics-server]# scp metrics-server-v0.6.3.tar node-2:/root
    metrics-server-v0.6.3.tar                             100%   67MB 151.7MB/s   00:00    
    [root@master metrics-server]# 
    
  3. 三台导入镜像

    shell">[root@node-1 ~]# docker load -i metrics-server-v0.6.3.tar 
    
  4. 启用metrics-server pod

    shell">[root@master metrics-server]# kubectl apply -f components.yaml 
    serviceaccount/metrics-server created
    clusterrole.rbac.authorization.k8s.io/system:aggregated-metrics-reader created
    clusterrole.rbac.authorization.k8s.io/system:metrics-server created
    rolebinding.rbac.authorization.k8s.io/metrics-server-auth-reader created
    clusterrolebinding.rbac.authorization.k8s.io/metrics-server:system:auth-delegator created
    clusterrolebinding.rbac.authorization.k8s.io/system:metrics-server created
    service/metrics-server created
    deployment.apps/metrics-server created
    apiservice.apiregistration.k8s.io/v1beta1.metrics.k8s.io created
    [root@master metrics-server]# 
    
    shell">[root@master metrics-server]# kubectl get pod -n kube-system|grep metrics
    metrics-server-769f6c8464-ctxl7            1/1     Running   0          49s
    [root@master metrics-server]# 
    
  5. 查看是否可用

    shell">[root@master metrics-server]# kubectl top node
    NAME     CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
    master   118m         5%     1180Mi          68%       
    node-1   128m         6%     985Mi           57%       
    node-2   60m          3%     634Mi           36%       
    [root@master metrics-server]# 
    
    shell">[root@master metrics-server]# kubectl top pod nginx 
    NAME    CPU(cores)   MEMORY(bytes)   
    nginx   0m           2Mi             
    [root@master metrics-server]# 
    
    shell">[root@master metrics-server]# kubectl top pod -n mem-example
    NAME            CPU(cores)   MEMORY(bytes)   
    memory-demo     30m          150Mi           
    memory-demo-3   32m          150Mi           
    [root@master metrics-server]# 
    

2、卷的使用

2.1、什么是卷?

当我们在容器中运行应用程序时,容器内的文件系统是临时的,容器停止后,其中的数据通常会丢失。卷(Volume)就是为了解决这一问题而设计的。卷提供了一种在容器之间共享保持数据的方法。

1. 解决数据持久性问题
  • 容器内文件系统是临时的,容器停止后数据丢失。
  • 卷提供持久存储,使数据在容器停止或重新启动时得以保留。
2. Kubernetes 中的卷抽象概念
  • 卷是对存储的一种抽象,可以连接到容器中。
  • 可将卷视为持久的存储空间,可被一个或多个容器访问。
3. 共享数据示例
  • 假设有一个运行在容器中的数据库应用。
  • 应用需要在容器停止后保留数据,以确保容器重新启动时能够继续工作。
4. Kubernetes 中的卷使用
  • 卷可以挂载到一个或多个容器中,实现数据共享。
  • 示例中,卷存储着配置文件,多个容器可以访问并共享这些文件。
  • 即使一个容器修改了文件,其他容器也能看到这些变化。
5. 不同类型的卷
  • 临时卷(Temporary Volumes)适合存储容器生命周期内的数据。
  • 持久卷(Persistent Volumes)适合在容器之间共享和保持数据。
6. 灵活、可靠的数据管理
  • 卷提供了灵活、可靠的方式,容器之间能够方便地共享和持久化数据。
  • 在构建复杂的应用系统中,卷是一个重要的工具。

2.2、联想到docker中的卷

docker 中的卷存放在 /var/lib/docker/volumes/

卷—>实现数据持久化

2.3、实践一下

https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/

  1. 在master上新建文件夹写yaml文件

    shell">[root@master ~]# mkdir /volume
    [root@master ~]# cd /volume/
    [root@master volume]# vim redis.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: redis
    spec:
      containers:
      - name: redis
        image: redis
        volumeMounts:
        - name: redis-storage
          mountPath: /data/redis
      volumes:
      - name: redis-storage
        emptyDir: {}
    [root@master volume]# 
    

    这是一个使用 Redis 镜像创建的 Pod 配置文件。让我来解释一下其中的内容:

    • apiVersion: v1:指定了 Kubernetes API 的版本。
    • kind: Pod:定义了这个配置文件描述的对象是一个 Pod。
    • metadata:包含了关于 Pod 的元数据,比如名称等。
      • name: redis:指定了 Pod 的名称为 “redis”。
    • spec:定义了 Pod 的规格,包括容器和卷的配置。
      • containers:定义了 Pod 中的容器列表。
        • name: redis:指定了容器的名称为 “redis”。
        • image: redis:指定了容器使用的镜像为 Redis。
        • volumeMounts:定义了容器挂载的卷。
          • name: redis-storage:指定了卷的名称为 “redis-storage”,与下方的卷配置中的名称对应。
          • mountPath: /data/redis:指定了卷在容器中的挂载路径为 “/data/redis”。
      • volumes:定义了 Pod 中的卷列表。
        • name: redis-storage:指定了卷的名称为 “redis-storage”,与上方的容器挂载中的名称对应。
        • emptyDir: {}:指定了一个空目录卷,表示该卷是一个临时的、空的存储空间。

    这个配置文件描述了一个包含一个 Redis 容器的 Pod,并且为该容器提供了一个临时的空目录卷,用于存储 Redis 数据。

  2. 执行yaml文件

    shell">[root@master volume]# kubectl apply -f redis.yaml 
    pod/redis created
    [root@master volume]# kubectl get pod
    NAME    READY   STATUS              RESTARTS   AGE
    nginx   1/1     Running             3          37h
    redis   0/1     ContainerCreating   0          6s
    [root@master volume]# kubectl get pod -o wide|grep redis
    redis   1/1     Running   0          61s   10.244.247.17   node-2   <none>           <none>
    [root@master volume]# 
    
  3. 查看redis pod的详细信息

    shell">[root@master volume]# kubectl describe pod redis
    Volumes:
      redis-storage:
        Type:       EmptyDir (a temporary directory that shares a pod's lifetime)
        Medium:     
        SizeLimit:  <unset>
      default-token-zdvg8:
        Type:        Secret (a volume populated by a Secret)
        SecretName:  default-token-zdvg8
        Optional:    false
    QoS Class:       Burstable
    '并没有指定宿主机上零时卷的路径在哪里'
    '但是按照常理来说是在对应node节点上的/var/lib/kubelet/pods下边'
    [root@node-2 ~]# cd /var/lib/kubelet/pods
    您在 /var/spool/mail/root 中有新邮件
    [root@node-2 pods]# ls
    0a95481c-c0f8-400d-8c19-0780c9c3950a  6d5da3b8-a8cc-4574-b349-cb66a434000d
    185a4899-96d4-4244-808b-d8dc91f01136  b6e26401-0091-4128-a6b4-6abd541d42c5
    237dbbfc-d7ef-4758-ad56-285225b3b9f9  f727c33a-f4d3-4420-b4cb-f043d01dd85f
    [root@node-2 pods]# 
    
  4. 进入redis容器查看(在master上就可以进入),卷的位置

    shell">[root@master volume]# kubectl exec redis -it -- bash
    root@redis:/data# pwd
    /data
    root@redis:/data# ls
    redis
    root@redis:/data# 
    
  5. 在redis目录下添加一个文件夹,去node-2中查看是否存在

    shell">root@redis:/data# cd redis/
    root@redis:/data/redis# mkdir gaohui
    root@redis:/data/redis# ls
    gaohui
    root@redis:/data/redis# 
    
    shell">[root@node-2 pods]# pwd
    /var/lib/kubelet/pods
    [root@node-2 pods]# find / -name gaohui
    /var/lib/kubelet/pods/185a4899-96d4-4244-808b-d8dc91f01136/volumes/kubernetes.io~empty-dir/redis-storage/gaohui
    [root@node-2 pods]# 
    

    卷会在node节点上创建

3、一个pod里启多个容器容器类型

3.1、写个简单的yaml文件

shell">[root@master volume]# cd /pod
[root@master pod]# mkdir pod2
[root@master pod]# cd pod2/
[root@master pod2]# 
[root@master pod2]# vim simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: sc-nginx
  namespace: sc 
spec:
  nodeName: node-2
  containers:
  - name: sc-nginx
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
  - name: sc-redis
    image: redis:latest
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379

[root@master pod2]# 

解释 YAML 文件:

  1. apiVersion: v1: 指定 Kubernetes API 版本为 v1。

  2. kind: Pod: 定义这个 YAML 文件描述的是一个 Pod 对象。

  3. metadata: 包含有关 Pod 的元信息。

    • name: sc-nginx: 指定 Pod 的名称为 “sc-nginx”。
    • namespace: sc: 将 Pod 放置在名为 “sc” 的命名空间中。
  4. spec: 定义了 Pod 的规格,包括容器、镜像、端口等配置。

    • containers: 定义了 Pod 中的容器列表。

      • 第一个容器
        • name: sc-nginx: 容器的名称是 “sc-nginx”。
        • image: nginx:latest: 使用的容器镜像是最新版本的 Nginx。
        • imagePullPolicy: IfNotPresent: 如果本地不存在该镜像,则从远程仓库拉取。
        • ports: 容器监听的端口配置,这里是 80 端口。
      • 第二个容器
        • name: sc-redis: 容器的名称是 “sc-redis”。
        • image: redis:latest: 使用的容器镜像是最新版本的 Redis。
        • imagePullPolicy: IfNotPresent: 如果本地不存在该镜像,则从远程仓库拉取。
        • ports: 容器监听的端口配置,这里是 6379 端口。
    • nodeName: node-2: 指定 Pod 被调度到名为 “node-2” 的节点上。

这份 YAML 文件描述了一个包含两个容器的 Pod,一个运行 Nginx,另一个运行 Redis。这个 Pod 被放置在 “sc” 命名空间中,且指定了调度到 “node-2” 节点上。

3.2、运行yaml文件

切记一定要创建命名空间,不然会报错

shell">[root@master pod2]# kubectl create namespace sc 
namespace/sc created
[root@master pod2]# kubectl apply -f simple-pod.yaml 
pod/sc-nginx created
[root@master pod2]# kubectl get pod -n sc -o wide
NAME       READY   STATUS    RESTARTS   AGE   IP              NODE     NOMINATED NODE   READINESS GATES
sc-nginx   2/2     Running   0          10s   10.244.247.19   node-2   <none>           <none>
[root@master pod2]# 
[root@master pod2]# kubectl top pod sc-nginx -n sc
NAME       CPU(cores)   MEMORY(bytes)   
sc-nginx   1m           3Mi             
[root@master pod2]# 

3.3、可不可以在yaml中同时创建pod和命名空间

apiVersion: v1
kind: Namespace
metadata:
  name: sc

---
apiVersion: v1
kind: Pod
metadata:
  name: sc-nginx
  namespace: sc 
spec:
  nodeName: node-2
  containers:
  - name: sc-nginx
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 80
  - name: sc-redis
    image: redis:latest
    imagePullPolicy: IfNotPresent
    ports:
    - containerPort: 6379
shell">[root@master pod2]# kubectl apply -f simple-pod.yaml 
namespace/sc2 created
pod/sc-nginx-redis created
[root@master pod2]# kubectl get pod -n sc2
NAME             READY   STATUS    RESTARTS   AGE
sc-nginx-redis   2/2     Running   0          12s
[root@master pod2]# 

3.4、进入pod中的容器

shell">[root@master pod2]# kubectl exec -n sc2 sc-nginx-redis -c sc-nginx -it -- /bin/bash
root@sc-nginx-redis:/# ls
bin   docker-entrypoint.d   home   media  proc	sbin  tmp
boot  docker-entrypoint.sh  lib    mnt	  root	srv   usr
dev   etc		    lib64  opt	  run	sys   var
root@sc-nginx-redis:/# cd /usr/share/nginx/
root@sc-nginx-redis:/usr/share/nginx# ls
html
root@sc-nginx-redis:/usr/share/nginx# cd html/
root@sc-nginx-redis:/usr/share/nginx/html# ls
50x.html  index.html

3.5、多个软件配合互相共享资源-sidecar

sidecar:边车

容器化的应用程序中,有时候我们希望多个容器能够共享资源或协同工作。为了实现这样的需求,可以使用一种设计模式称为Sidecar

Sidecar 是一种附加到主要容器旁边的辅助容器。主要容器是应用程序的核心组件,而 Sidecar 则提供了额外的功能和服务。Sidecar 容器与主要容器运行在同一个 Pod 中,它们共享相同的网络和存储空间,可以通过本地主机通信。

Sidecar 容器可以提供各种不同的功能,例如:

  1. 日志收集:Sidecar 容器可以负责收集主要容器的日志,并将其发送到中央日志系统,以便进行集中管理和分析。
  2. 监控和指标收集:Sidecar 容器可以收集主要容器的监控数据和指标,并将其发送到监控系统,以便进行实时监控和分析。
  3. 安全代理:Sidecar 容器可以作为安全代理,处理主要容器的网络流量加密、认证和授权等安全功能。
  4. 数据同步:Sidecar 容器可以负责将主要容器产生的数据同步到外部存储系统,或者从外部存储系统读取数据并同步到主要容器
  5. 缓存代理:Sidecar 容器可以作为缓存代理,提供缓存服务,加速主要容器的访问速度。
  6. 动态配置:Sidecar 容器可以负责动态更新主要容器的配置,以适应不同的环境和需求。

通过将这些功能模块化为 Sidecar 容器,我们可以实现更好的代码隔离、模块化和可维护性。同时,由于 Sidecar 容器与主要容器运行在同一个 Pod 中,它们之间可以通过本地主机通信,减少了网络开销和延迟。

总而言之,Sidecar 是一种在容器化应用程序中实现多个容器共享资源和协同工作的设计模式,可以提供额外的功能和服务,以提高应用程序的可扩展性、可靠性和安全性。

3.6、利用边车模式去写个yaml,对日志的记录

shell">[root@master pod]# mkdir log
[root@master pod]# cd log/
[root@master log]# vim two-file-counter-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}
[root@master log]# 

这是一个 Kubernetes Pod 的 YAML 文件,用于创建一个包含两个容器的 Pod,每个容器都在不断地向文件写入计数和时间信息。以下是对 YAML 文件的解释:

  • apiVersion: 定义 Kubernetes API 的版本,这里是 v1。

  • kind: 定义要创建的 Kubernetes 资源类型,这里是 Pod。

  • metadata: 包含有关 Pod 的元信息。

    • name: 指定 Pod 的名称为 “counter”。
  • spec: 定义了 Pod 的规格,包括容器和卷的配置。

    • containers: 定义 Pod 中的容器列表。
      • name: count: 第一个容器的名称为 “count”。
      • image: busybox:1.28: 使用的容器镜像是 BusyBox 1.28。
      • args: 定义容器的启动参数。
      • 容器内运行的脚本,不断向两个不同的文件写入计数和时间信息,其中 /var/log/1.log 包含计数和时间信息,而 /var/log/2.log 包含时间信息和附加的 INFO 标签。
      • volumeMounts: 挂载卷到容器的指定路径。
        • name: varlog: 指定卷的名称。
        • mountPath: /var/log: 将卷挂载到容器/var/log 路径下。
    • volumes: 定义 Pod 中使用的卷。
      • name: varlog: 定义一个名为 “varlog” 的卷。
      • emptyDir: {}: 使用空目录作为卷,这意味着该卷的生命周期与 Pod 相同,但可以在 Pod 中的不同容器之间共享数据。

这个 Pod 包含两个容器,一个叫做 “count”,它负责不断地往两个文件写入计数和时间信息。这个示例主要用于演示容器内的文件共享。其中,/var/log/1.log/var/log/2.log 是通过挂载名为 “varlog” 的空目录卷实现的。

shell">[root@master log]# kubectl apply -f two-file-counter-pod.yaml 
pod/counter created
[root@master log]# kubectl get pod
NAME      READY   STATUS    RESTARTS   AGE
counter   1/1     Running   0          25s
[root@master log]# 
[root@master log]# kubectl apply -f two-file-counter-pod.yaml 
pod/counter created
[root@master log]# kubectl get pod
NAME      READY   STATUS    RESTARTS   AGE
counter   1/1     Running   0          25s
nginx     1/1     Running   3          43h
redis     1/1     Running   0          5h13m
[root@master log]# kubectl exec counter -it -- sh
/ # cd /var/log/
/var/log # ls
1.log  2.log
/var/log # cat 1.log 
0: Thu Mar  7 09:15:32 UTC 2024
1: Thu Mar  7 09:15:33 UTC 2024
2: Thu Mar  7 09:15:34 UTC 2024
3: Thu Mar  7 09:15:35 UTC 2024
4: Thu Mar  7 09:15:36 UTC 2024
5: Thu Mar  7 09:15:37 UTC 2024
6: Thu Mar  7 09:15:38 UTC 2024
7: Thu Mar  7 09:15:39 UTC 2024
8: Thu Mar  7 09:15:40 UTC 2024
9: Thu Mar  7 09:15:41 UTC 2024

3.7、进一步做边车实验

image-20240307172026898

[root@master log]# vim sidecar-1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox:1.28
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done      
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox:1.28
    args: [/bin/sh, -c, 'tail -n+1 -F /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox:1.28
    args: [/bin/sh, -c, 'tail -n+1 -F /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}
[root@master log]# 

这是一个 Kubernetes Pod 的 YAML 文件,创建了一个包含三个容器的 Pod,其中一个容器用于不断地向两个文件写入计数和时间信息,而另外两个容器则分别用于监视这两个文件的内容。以下是对 YAML 文件的解释:

  • apiVersion: 定义 Kubernetes API 的版本,这里是 v1。

  • kind: 定义要创建的 Kubernetes 资源类型,这里是 Pod。

  • metadata: 包含有关 Pod 的元信息。

    • name: 指定 Pod 的名称为 “counter”。
  • spec: 定义了 Pod 的规格,包括容器和卷的配置。

    • containers: 定义 Pod 中的容器列表。
      • name: count: 第一个容器的名称为 “count”。
        • image: busybox:1.28: 使用的容器镜像是 BusyBox 1.28。
        • args: 定义容器的启动参数。
        • 容器内运行的脚本,不断向两个文件写入计数和时间信息,其中 /var/log/1.log 包含计数和时间信息,而 /var/log/2.log 包含时间信息和附加的 INFO 标签。
        • volumeMounts: 挂载卷到容器的指定路径。
          • name: varlog: 指定卷的名称。
          • mountPath: /var/log: 将卷挂载到容器/var/log 路径下。
      • name: count-log-1: 第二个容器的名称为 “count-log-1”。
        • image: busybox:1.28: 使用的容器镜像是 BusyBox 1.28。
        • args: 定义容器的启动参数,用于监视 /var/log/1.log 文件的内容。
        • volumeMounts: 挂载卷到容器的指定路径。
          • name: varlog: 指定卷的名称。
          • mountPath: /var/log: 将卷挂载到容器/var/log 路径下,以便与第一个容器共享文件。
      • name: count-log-2: 第三个容器的名称为 “count-log-2”。
        • image: busybox:1.28: 使用的容器镜像是 BusyBox 1.28。
        • args: 定义容器的启动参数,用于监视 /var/log/2.log 文件的内容。
        • volumeMounts: 挂载卷到容器的指定路径。
          • name: varlog: 指定卷的名称。
          • mountPath: /var/log: 将卷挂载到容器/var/log 路径下,以便与第一个容器共享文件。
    • volumes: 定义 Pod 中使用的卷。
      • name: varlog: 定义一个名为 “varlog” 的卷。
      • emptyDir: {}: 使用空目录作为卷,这意味着该卷的生命周期与 Pod 相同,但可以在 Pod 中的不同容器之间共享数据。
shell">[root@master log]# kubectl apply -f sidecar-1.yaml 
pod/counter created
[root@master log]# kubectl get pod
NAME      READY   STATUS    RESTARTS   AGE
counter   3/3     Running   0          6s
shell">[root@master log]# kubectl logs counter count-log-1 #看日志
0: Thu Mar  7 09:31:23 UTC 2024
1: Thu Mar  7 09:31:24 UTC 2024
2: Thu Mar  7 09:31:25 UTC 2024
. . .
shell">[root@master log]# kubectl logs counter count-log-2 #看日志
Thu Mar  7 09:31:23 UTC 2024 INFO 0
Thu Mar  7 09:31:24 UTC 2024 INFO 1
Thu Mar  7 09:31:25 UTC 2024 INFO 2
Thu Mar  7 09:31:26 UTC 2024 INFO 3
. . . 

4、容器类型

4.1、sidecar

sidecar:边车

容器化的应用程序中,有时候我们希望多个容器能够共享资源或协同工作。为了实现这样的需求,可以使用一种设计模式称为Sidecar

Sidecar 是一种附加到主要容器旁边的辅助容器。主要容器是应用程序的核心组件,而 Sidecar 则提供了额外的功能和服务。Sidecar 容器与主要容器运行在同一个 Pod 中,它们共享相同的网络和存储空间,可以通过本地主机通信。

Sidecar 容器可以提供各种不同的功能,例如:

  1. 日志收集:Sidecar 容器可以负责收集主要容器的日志,并将其发送到中央日志系统,以便进行集中管理和分析。
  2. 监控和指标收集:Sidecar 容器可以收集主要容器的监控数据和指标,并将其发送到监控系统,以便进行实时监控和分析。
  3. 安全代理:Sidecar 容器可以作为安全代理,处理主要容器的网络流量加密、认证和授权等安全功能。
  4. 数据同步:Sidecar 容器可以负责将主要容器产生的数据同步到外部存储系统,或者从外部存储系统读取数据并同步到主要容器
  5. 缓存代理:Sidecar 容器可以作为缓存代理,提供缓存服务,加速主要容器的访问速度。
  6. 动态配置:Sidecar 容器可以负责动态更新主要容器的配置,以适应不同的环境和需求。

通过将这些功能模块化为 Sidecar 容器,我们可以实现更好的代码隔离、模块化和可维护性。同时,由于 Sidecar 容器与主要容器运行在同一个 Pod 中,它们之间可以通过本地主机通信,减少了网络开销和延迟。

总而言之,Sidecar 是一种在容器化应用程序中实现多个容器共享资源和协同工作的设计模式,可以提供额外的功能和服务,以提高应用程序的可扩展性、可靠性和安全性。

4.2、pause容器

创建pod的时候最先创建的容器

在Kubernetes中,每个Pod都有一个特殊的容器称为pause容器。这个容器是由Kubernetes自动添加到每个Pod中的,它在技术上并不执行任何有用的工作。让我们来解释一下pause容器的作用和原理。

pause容器的主要目的是创建一个网络命名空间(network namespace)和一个IPC命名空间(inter-process communication namespace),并在这些命名空间中挂载一个共享的网络和IPC命名空间。这个共享的命名空间允许Pod中的其他容器共享网络和进程间通信。

具体来说,当Pod创建时,Kubernetes会创建一个共享网络命名空间和IPC命名空间,并在这些命名空间中启动一个"pause"容器。然后,Pod中的其他容器会以pause容器的命名空间作为基础,与``pause`容器共享网络和IPC。

这种设计的好处是,通过共享命名空间,Pod中的容器可以直接通过localhost进行通信,而无需进行网络转发或IPC机制。同时,通过将网络和IPC命名空间与pause容器分离,可以实现更好的资源隔离和安全性。

需要注意的是,pause容器本身不会执行任何实际的任务或应用程序代码。它只是一个占位符容器,用于创建和管理共享的网络和IPC命名空间。

总结起来,pause容器在Kubernetes中起到了创建和管理共享网络和IPC命名空间的作用,使得Pod中的其他容器可以直接通过localhost进行通信。它是Kubernetes网络和容器隔离机制的关键组成部分。

042c895fc3ae409dd18de7d0f4d3af1

65674048f0fd24ba907d649aa2ab578

pause容器–》把pod的公用的命名空间都创建好–》init容器—》app容器

4.3、init 初始化容器(Init Container)

Kubernetes中,每个Pod可以包含一个或多个初始化容器(Init Container)。初始化容器是在Pod中的其他容器启动之前运行的短暂容器,用于执行一些初始化任务或准备工作。

是有先后顺序的!

init容器是去铺路的,第一批拓荒的人,像极了《剑来》中的仙蔚道长,他是开路之人。

总结起来,初始化容器是在Pod中运行的短暂容器,用于执行一次性的初始化任务或准备工作。通过初始化容器,可以实现在启动其他容器之前完成一些必要的操作,如加载配置、初始化数据库等。

image-20240307175815155

相当于:我必须先启动:redis,mysql和nginx 容器,才能启动主容器:flask web 不然跑不起来

下面的例子定义了一个具有 2 个 Init 容器的简单 Pod。 第一个等待 myservice 启动, 第二个等待 mydb 启动。 一旦这两个 Init 容器都启动完成,Pod 将启动 spec 节中的应用容器

[root@master pod]# mkdir init
[root@master pod]# cd init/
[root@master init]# vim 1.yaml
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app.kubernetes.io/name: MyApp
spec:
  containers:
  - name: myapp-container
    image: busybox:1.28
    command: ['sh', '-c', 'echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup myservice.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for myservice; sleep 2; done"]
  - name: init-mydb
    image: busybox:1.28
    command: ['sh', '-c', "until nslookup mydb.$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace).svc.cluster.local; do echo waiting for mydb; sleep 2; done"]
shell">[root@master init]# kubectl apply -f 1.yaml 
pod/myapp-pod created
[root@master init]# kubectl get pod -o wide
NAME        READY   STATUS     RESTARTS   AGE    IP              NODE     NOMINATED NODE   READINESS GATES
myapp-pod   0/1     Init:0/2   0          15s    10.244.247.21   node-2   <none>           <none>
[root@master init]# 

Init状态---->初始化状态

shell">[root@master init]# kubectl logs myapp-pod -c init-myservice #看日志
nslookup: can't resolve 'myservice.default.svc.cluster.local'
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
waiting for myservice
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

创建服务:

[root@master init]# vim myservice.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377
[root@master init]# 

查看状态

shell">[root@master init]# kubectl apply -f myservice.yaml 
service/myservice created
service/mydb created
[root@master init]# kubectl get -f 1.yaml 
NAME        READY   STATUS    RESTARTS   AGE
myapp-pod   1/1     Running   0          4m46s
[root@master init]# 

4.4、app容器

应用程序容器—》跑业务代码的容器

5、服务发现

让外面的人发现k8s集群内部的服务

pod: 提供web—》在k8s集群内部的 --》ip 私网ip地址

server —》定义服务–》去发布k8s内部的pod,让外面的机器可以访问集群内部的pod

本质上其实是在做DNAT

6、小练习

自己写yaml文件,启动一个pod,里面有2个容器,具体的自己定 启动nginx容器 启动一个busybox容器 定义卷,两个容器都挂着这个卷

[root@master lianxi]# vim my.yaml 
apiVersion: v1
kind: Namespace
metadata:
  name: halou-gh

---
apiVersion: v1
kind: Pod
metadata:
  name: gh-nginx-busybox
  namespace: halou-gh
spec:
  nodeName: node-1
  containers:
  - name: gh-nginx
    image: nginx:latest
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: vargh
      mountPath: /var/gh
    ports:
    - containerPort: 80
  - name: gh-busybox
    image: busybox:latest
    imagePullPolicy: IfNotPresent
    command: ["/bin/sh"]
    args: ["-c", "i=0; while true; do echo \"$i: $(date)\" >> /var/gh/1.log; i=$((i+1)); sleep 1; done"]
    volumeMounts:
    - name: vargh
      mountPath: /var/gh
  volumes:
  - name: vargh
    emptyDir: {}
[root@master lianxi]# 
shell">[root@master lianxi]# kubectl apply -f my.yaml 
namespace/halou-gh created
pod/gh-nginx-busybox created
[root@master lianxi]# kubectl get pod -n halou-gh
NAME               READY   STATUS    RESTARTS   AGE
gh-nginx-busybox   2/2     Running   0          12s
[root@master lianxi]# 

在这遇到个问题,就是写yaml的时候,busybox 我没有动作,他进入容器之后,就会启动后立即完成(Completed)而不是保持运行状态。这通常表明容器执行的任务已完成,然后容器自动退出。这就使得:BusyBox 容器中,它只运行了一次,并在任务完成后退出。

所以得加个动作:sleep 命令添加到启动命令中,以保持容器处于运行状态。

> command: ["/bin/sh"]
>   args: ["-c", "i=0; while true; do echo \"$i: $(date)\" >> /var/gh/1.log; i=$((i+1)); sleep 1; done"]

http://www.niftyadmin.cn/n/5412565.html

相关文章

apt-get update 和 apt-get upgrade的区别

apt-get update和apt-get upgrade是Linux系统中用于软件包管理的两个命令&#xff0c;它们的主要区别在于功能和作用对象的不同。 apt-get update&#xff1a;这个命令用于同步本地的软件包列表与远程仓库的信息&#xff0c;即更新可用软件包及其版本的列表。换句话说&#xf…

redis未设置密码被植入挖矿脚本

最近一台测试linux响应速度贼慢&#xff0c;检查发现cpu消耗高达100%&#xff01;查看进程杀死后过段时间又重启了&#xff0c;一时间也摸不到头绪。无意间发现启动redis的时候cpu瞬间拉到了100%&#xff0c;主要就是zzh和newinit.sh两个脚本。百度了一下说是被植入了挖矿脚本&…

Qt:基于QQuickFramebufferObject显示QImage到QML中

GItHub地址 简介 本仓库实现了一个在QML框架中&#xff0c;显示QImage数据的QML控件&#xff0c;取名为JQImageItem 本控件针对的场合是需要显示并且频繁修改QImage的场景&#xff0c;例如视频显示。 提供了2个实现版本&#xff0c;一个是基于QQuickFramebufferObject&…

深度解析:HEC-RAS、ArcGIS、HEC-HMS等技术在防洪评价、城市内涝、山洪防治、水土流失应用方面的特点和优势

目录 ★基于多案例系统学习防洪评价报告编制方法与水流数学模型建模 ★HEC-RAS一维、二维建模方法及应用 ★HEC-HMS水文模型应用 ★全流程HEC-RAS 1D2D水动力与水环境模拟技术案例实践及拓展应用 ★基于ArcGIS水文分析、HEC-RAS模拟技术在洪水危险性及风险评估 ★ArcGIS在…

【学习笔记】数据结构与算法06 - 堆:上堆、下堆、Top-K问题以及代码实现

知识来源&#xff1a;https://www.hello-algo.com/chapter_heap/heap/#4 文章目录 2.5 堆2.5.1 堆&#xff08;优先队列2.5.1.1 堆的常用操作 2.5.2 堆的存储与表示2.5.2.1 访问堆顶元素2.5.2.2 入堆时间复杂度 2.5.2.3 堆顶元素出堆时间复杂度 2.5.3 堆的常见应用2.5.4 建堆问…

【图像拼接/视频拼接】论文精读:Efficient Video Stitching Based on Fast Structure Deformation

第一次来请先看这篇文章:【图像拼接(Image Stitching)】关于【图像拼接论文精读】专栏的相关说明,包含专栏使用说明、创新思路分享等(不定期更新) 图像拼接系列相关论文精读 Seam Carving for Content-Aware Image ResizingAs-Rigid-As-Possible Shape ManipulationAdap…

浅谈社会工程学攻击

一、前言 1.1 社会工程学起源 社会工程学是黑客米特尼克在《欺骗的艺术》中所提出&#xff0c;其初始目的是让全球的网民们能够懂得网络安全&#xff0c;提高警惕&#xff0c;防止没必要的个人损失。但在我国黑客集体中还在不断使用其手段欺骗无知网民制造违法行为&#xff0c;…

Python教程:time.perf_counter()计算程序运行的时间

time.perf_counter() 是 Python 中的一个函数&#xff0c;它属于 time 模块。它用于测量代码的执行时间&#xff0c;提供了一个高分辨率的性能计数器&#xff0c;通常用于基准测试、性能分析和时间测量。 以下是关于 time.perf_counter() 的一些关键点&#xff1a; 高分辨率&…