Kubenertes on Ricardo

Pod 多容器启动顺序与 Init Container 笔记

Wed, 13 Mar 2024 16:55:49 +0800

pod内多个容器启动问题

问题描述

apiVersion: v1
kind: Pod
metadata:
  name: mc3
  labels:
    app: mc3
spec:
  containers:
  - name: webapp
    image: training/webapp
  - name: nginx
    image: nginx:alpine
    ports:
    - containerPort: 80
    volumeMounts:
    - name: nginx-proxy-config
      mountPath: /etc/nginx/nginx.conf
      subPath: nginx.conf
  volumes:
  - name: nginx-proxy-config
    configMap:
      name: mc3-nginx-conf

如上的pod容器启动，在一个pod内有多个容器的启动顺序问题，这种算不算 sidecar 模式

找到一个解释

In what order containers are being started in a Pod?

Currently, all containers in a Pod are being started in parallel and there is no way to define that one container must be started after other container (however, there are Kubernetes Init Containers). Therefore, in your IPC example there is a chance that the second container starts before the first one. In this case, the second container will fail, because in the consumer mode it expects that the message queue exists. To fix this issue we, for example, can change the application to wait for the message queue to be created.

翻译(微软翻译)：目前，Pod 中的所有容器都是并行启动的，并且无法定义一个容器必须在另一个容器之后启动（但是，有 Kubernetes 初始化容器）。因此，在 IPC 示例中，第二个容器有可能在第一个容器之前启动。在这种情况下，第二个容器将失败，因为在 consumer 该模式下，它期望消息队列存在。例如，为了解决此问题，我们可以更改应用程序以等待创建消息队列。

原文链接

解决方案1

具体的版本不清楚了，但这种方式用的人不多。或者用的是initContainers

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

案例来自官网

Docker 数据目录、日志与 Registry 配置笔记

Sun, 14 Jan 2024 17:50:26 +0800

docker 迁移

systemctl enable docker
systemctl start docker
# 增加普通用户管理docker权限
usermod -aG docker your-user
# 修改docker挂载目录
systemctl stop docker
systemctl stop docker.socket
mv /var/lib/docker /data/
ln -s /data/docker /var/lib/docker
systemctl start docker

docker log

docker logs -f -t –tail 100 CONTAINER_ID

$ docker logs [OPTIONS] CONTAINER
  Options:
        --details        显示更多的信息
    -f, --follow         跟踪实时日志
        --since string   显示自某个timestamp之后的日志，或相对时间，如42m（即42分钟）
        --tail string    从日志末尾显示多少行日志， 默认是all
    -t, --timestamps     显示时间戳
        --until string   显示自某个timestamp之前的日志，或相对时间，如42m（即42分钟）

查看指定时间后的日志，只显示最后100行

`1`	`$ docker logs -f -t --since="2018-02-08" --tail=100 CONTAINER_ID`

查看最近30分钟的日志

`1`	`$ docker logs --since 30m CONTAINER_ID`

查看某时间之后的日志

`1`	`$ docker logs -t --since="2018-02-08T13:23:37" CONTAINER_ID`

查看某时间段日志

`1`	`$ docker logs -t --since="2018-02-08T13:23:37" --until "2018-02-09T12:23:37" CONTAINER_ID`

允许Docker使用无权限验证的Docker Registry

配置insecure-registries，docker才能使用无权限验证的docker registry

默认情况下，Docker不能使用没有配置权限验证的Docker Registry，会出现如下报错：

1
2

docker pull registry.example.com:5000/ubuntu
Error response from daemon: server gave HTTP response to HTTPS client

这时需要修改 Docker 配置文件，将示例 Registry 地址 registry.example.com:5000 添加到 insecure-registries 中：

cat /etc/docker/daemon.json
{
  "insecure-registries" : ["registry.example.com:5000"]
}

然后重启docker

`1`	`systemctl restart docker`

容器内部操作

debain 系统换清华源，执行下列命令，换源然后安装应用

echo -e "# 默认注释了源码镜像以提高 apt update 速度，如有需要可自行取消注释\ndeb https://mirrors.tuna.tsinghua.edu.cn/debian/ buster main contrib non-free\n# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ buster main contrib non-free\ndeb https://mirrors.tuna.tsinghua.edu.cn/debian/ buster-updates main contrib non-free\n# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ buster-updates main contrib non-free\ndeb https://mirrors.tuna.tsinghua.edu.cn/debian/ buster-backports main contrib non-free\n# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ buster-backports main contrib non-free\ndeb https://mirrors.tuna.tsinghua.edu.cn/debian-security buster/updates main contrib non-free\n# deb-src https://mirrors.tuna.tsinghua.edu.cn/debian-security buster/updates main contrib non-free" >> /etc/apt/sources.list

容器暴露端口

当容器内部没有启动一个端口，但外部暴露这个端口，现象: 宿主机会启动这个端口，端口被占用，但访问这个端口会失败，curl会提示

`1`	`curl: (56) Recv failure: Connection reset by peer`

进程退出码 130、137、143 与信号

Sun, 14 Jan 2024 17:50:26 +0800

k8s kill restart exit status 137

128+信号值

exit 130 命令行输入 sleep 100000 然后执行查看命令状态 echo $? 结果输出: 130(128+2)

exit 137 终端1:命令行输入: sleep 100000 终端2:kill sleep 终端1:查看命令状态 echo $? 结果输出: 137(128+9)

143 ps aux | grep sleep | grep -v grep | awk ‘{print $2}’ kill -term kill -15

Ingress NGINX 部署与 RBAC 学习笔记

Fri, 17 Nov 2023 18:34:52 +0800

kubernetes deploy ingress-controller

会启动job，是一次性任务。主要是创建证书使用

docker 镜像使用 orbstack 当成 docker 容器会开启 docker 最新实验特性，根据芯片下载对应的版本，这也算一个坑

yaml 文件提供的镜像地址都是国外的，需要转换为国内的，刚好也自建 nexus docker 仓库，需要配置服务器配置 docker 信任源

{
    "storage-driver": "overlay2",
    "insecure-registries" : ["registry.example.com:5000"]
}

当前对应的k8s版本是 1.23，(官网提示)能安装的 ingress 版本 v1.3.0、v1.3.1、v1.4.0、v1.5.1、v1.6.4

之前找到一个 ingress 安装入门文档，结果文档太老，使用的是 v0.15.0镜像，对应的部署控制器还是 rc ，这个控制器在 0.47这个版本里已经被删除了。相关文档链接，吐槽一句，国内文档还是有点跨，不够新。

https://blog.csdn.net/zhou920786312/article/details/126246557 比较老

https://ytool.cloud/k8s/net/ingress/install.html ，这个文档比较新，但我没有采用，因为不是很想用helm 无脑安装，不清楚做了啥

https://www.cnblogs.com/wtzbk/p/15427237.html 这个版本比较新，但我没用 https://cloud.tencent.com/developer/article/1579931 这个讲的也行，只有回过头才知道哪些是对的

`1`	`registry.k8s.io/ingress-nginx/controller:v1.9.4@sha256:5b161f051d017e55d358435f295f5e9a297e66158f136321d9b04520ec6c48a3`

后面的@sha 表示文件的校验码，类似 md5，我直接下载这个链接的时候，发现下载的镜像没有对应的版本，后来还是指定版本了

安装 ingress 的 yaml 文件里有job，这个是一次性的任务，如果执行报错了，再次执行

`1`	`kubectl apply -f ingress-nginx.yaml`

会提示报错，需要执行删除 job 命令

`1`	`kubectl delete job --all -n ingress-nginx --context=huawei`

查看容器是否启动，直接看应用是否 ready

`1`	`kubectl get po -n ingress-nginx --context=huawei -w`

-w 表示–watch，就是监视，在 watch 的时候出现一次弹出多条重复的信息，表示有多个变动，只是展示信息不够详细只能看到多条重复信息，不是实现故障，信息重复

容器未启动需要查看事件 events

`1`	`kubectl describe po xxx`

查看事件只提示拉镜像成功，没有更多的有用信息，就需要在看看容器日志

`1`	`kubectl logs xxx`

ingress-nginx.yaml 文件解释

创建两个账户 ServiceAccount

ingress-nginx
ingress-nginx-admission 区别在于 ingress-nginx 设置了 automountServiceAccountToken: true 属于 namespace 下自动调用的 token，不需要在调用时指定 ServiceAccountName

1
2

使用默认的 Service Account 访问 API server
当您创建 pod 的时候，如果您没有指定一个 service account，系统会自动得在与该pod 相同的 namespace 下为其指派一个default service account。如果您获取刚创建的 pod 的原始 json 或 yaml 信息（例如使用kubectl get pods/podename -o yaml命令），您将看到spec.serviceAccountName字段已经被设置为 default。

然后就是对应的 Role ClusterRole RoleBinding ClusterRoleBinding

ServiceAccount(ingress-nginx) –RoleBinding–> Role(ingress-nginx) ServiceAccount(ingress-nginx) –ClusterRoleBinding–> ClusterRole(ingress-nginx)

ServiceAccount(ingress-nginx-admission) –RoleBinding–> Role(ingress-nginx-admission) ServiceAccount(ingress-nginx-admission) –ClusterRoleBinding–> ClusterRole(ingress-nginx-admission)

标准的 rbac 那一套，指定当前账户有哪个角色，角色对应的有哪些资源(pod/configmap/service…)的哪些权限(get/list/update/watch…)

在 deployment 中用到了 serviceAccountName: ingress-nginx 在 2 个 job 中用到了 serviceAccountName: ingress-nginx-admission

下面是一个摘要

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:...
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  minReadySeconds: 0
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app.kubernetes.io/component: controller
      app.kubernetes.io/instance: ingress-nginx
      app.kubernetes.io/name: ingress-nginx
  strategy:...
  template:
    metadata:
      labels:...
    spec:
      containers:
      - args:...
      dnsPolicy: ClusterFirst
      nodeSelector:...
      serviceAccountName: ingress-nginx
      terminationGracePeriodSeconds: 300
      volumes:...

apiVersion: batch/v1
kind: Job
metadata:
  labels:
    app.kubernetes.io/component: admission-webhook
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.5.1
  name: ingress-nginx-admission-create
  namespace: ingress-nginx
spec:
  template:
    metadata:
      labels:
        app.kubernetes.io/component: admission-webhook
        app.kubernetes.io/instance: ingress-nginx
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
        app.kubernetes.io/version: 1.5.1
      name: ingress-nginx-admission-create
    spec:
      containers:
      - args:
        - create
        - --host=ingress-nginx-controller-admission,ingress-nginx-controller-admission.$(POD_NAMESPACE).svc
        - --namespace=$(POD_NAMESPACE)
        - --secret-name=ingress-nginx-admission
        env:
        - name: POD_NAMESPACE
          valueFrom:...
        image: registry.k8s.io/ingress-nginx/kube-webhook-certgen:v20220916-gd32f8c343@sha256:39c5b2e3310dc4264d638ad28d9d1d96c4cbb2b2dcfb52368fe4e3c63f61e10f
        imagePullPolicy: IfNotPresent
        name: create
        securityContext:...
      nodeSelector:...
      restartPolicy: OnFailure
      securityContext:...
      serviceAccountName: ingress-nginx-admission

ValidatingWebhookConfiguration 描述准入Webhook 的配置，该Webhook 可在不更改对象的情况下接受或拒绝对象请求。

准入 Webhook 是一种用于接收准入请求并对其进行处理的 HTTP 回调机制。可以定义两种类型的准入 Webhook，即验证性质的准入 Webhook 和变更性质的准入 Webhook。变更性质的准入 Webhook 会先被调用。它们可以修改发送到 API 服务器的对象以执行自定义的设置默认值操作。