Kubernetes-3

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、容器类型
- - 4.1、sidecar
  - 4.2、pause容器
  - 4.3、init 初始化容器(Init Container)
  - 4.4、app容器
- 5、服务发现
- 6、小练习

Kubernetes-3

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

1.1、kubectl top node

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

在外界下载下：metrics-server的yaml文件，然后上传到虚拟机，进行解压
```
[root@master pod]# unzip metrics-server.zip 
[root@master pod]# 
```

进入metrics-server文件夹，把tar包传递给node节点

[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]#

三台导入镜像

[root@node-1 ~]# docker load -i metrics-server-v0.6.3.tar

启用metrics-server pod

[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]#

[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]#

查看是否可用

[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]#

[root@master metrics-server]# kubectl top pod nginx 
NAME    CPU(cores)   MEMORY(bytes)   
nginx   0m           2Mi             
[root@master metrics-server]#

[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/

在master上新建文件夹写yaml文件
```
[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 数据。

执行yaml文件

[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]#

查看redis pod的详细信息

[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]#

进入redis容器查看(在master上就可以进入),卷的位置

[root@master volume]# kubectl exec redis -it -- bash
root@redis:/data# pwd
/data
root@redis:/data# ls
redis
root@redis:/data#

在redis目录下添加一个文件夹，去node-2中查看是否存在

root@redis:/data# cd redis/
root@redis:/data/redis# mkdir gaohui
root@redis:/data/redis# ls
gaohui
root@redis:/data/redis#

[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文件

[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 文件:

apiVersion: v1: 指定 Kubernetes API 版本为 v1。
kind: Pod: 定义这个 YAML 文件描述的是一个 Pod 对象。
metadata: 包含有关 Pod 的元信息。
- name: sc-nginx: 指定 Pod 的名称为 “sc-nginx”。
- namespace: sc: 将 Pod 放置在名为 “sc” 的命名空间中。
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文件

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

[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

[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中的容器

[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 容器可以提供各种不同的功能，例如：

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

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

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

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

[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” 的空目录卷实现的。

[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、进一步做边车实验

[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 中的不同容器之间共享数据。

[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

[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
. . .

[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 容器可以收集主要容器的监控数据和指标，并将其发送到监控系统，以便进行实时监控和分析。
安全代理：Sidecar 容器可以作为安全代理，处理主要容器的网络流量加密、认证和授权等安全功能。
数据同步：Sidecar 容器可以负责将主要容器产生的数据同步到外部存储系统，或者从外部存储系统读取数据并同步到主要容器。
缓存代理：Sidecar 容器可以作为缓存代理，提供缓存服务，加速主要容器的访问速度。
动态配置：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中运行的短暂容器，用于执行一次性的初始化任务或准备工作。通过初始化容器，可以实现在启动其他容器之前完成一些必要的操作，如加载配置、初始化数据库等。

相当于：我必须先启动：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"]

[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状态---->初始化状态

[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]#

查看状态

[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]#

[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"]

Kubernetes-3

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、容器类型

4.1、sidecar

4.2、pause容器

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

4.4、app容器

5、服务发现

6、小练习

相关文章