Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New design for basefs. #1909

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

New design for basefs. #1909

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
cf7b411
New design for basefs.
VinceCui Dec 7, 2022
951d5b6
Update.
VinceCui Dec 14, 2022
ec9d2b5
Update.
VinceCui Dec 14, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
59 changes: 17 additions & 42 deletions docs/api/cloudrootfs.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ cloud rootfs will package all the dependencies refers to the kubernetes cluster

```shell script
.
├── bin
├── bin # binaries will be installed at all nodes' /usr/local/bin
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we only store binaries in this directory, I am wondering whether it is proper to container scripts here, like containerd-rootless-setuptool.sh, containerd-rootless.sh and kubelet-pre-start.sh.

In addition, binary may not be compatible with plarforms(x86, arm). Then in the design, we make a ClusterImage to be compatible to all arch platforms or different ClusterImage compatible to different platforms.

It could be better that we have a top-down through design, I think. 🐱

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree with that. It's weird to have a bunch of shell scripts in a directory called bin

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, the binaries should be installed at the system PATH of all nodes, and the specific path should be compatible with the operating system which is determined by the installation script.

│ ├── conntrack
│ ├── containerd-rootless-setuptool.sh
│ ├── containerd-rootless.sh
Expand All @@ -13,44 +13,28 @@ cloud rootfs will package all the dependencies refers to the kubernetes cluster
│ ├── kubectl
│ ├── kubelet
│ ├── nerdctl
│ ├── kubelet-pre-start.sh
│ ├── helm
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if a dual-architecture cluster image, such as support for both amd64 and arm64?

I think we should have a relatively complete example.

│ └── seautil
├── cri
│ ├── containerd
│ ├── containerd-shim
│ ├── containerd-shim-runc-v2
│ ├── ctr
│ ├── docker
│ ├── dockerd
│ ├── docker-init
│ ├── docker-proxy
│ ├── rootlesskit
│ ├── rootlesskit-docker-proxy
│ ├── runc
│ └── vpnkit
├── etc
├── etc # configs will be put into all nodes' sealer-rootfs
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does sealer-rootfs? Could you help to define that? Since there are quite a lot of rootfs in sealer's concept. @VinceCui

│ ├── 10-kubeadm.conf
│ ├── Clusterfile # image default Clusterfile
│ ├── daemon.json
│ ├── docker.service
│ ├── audit-policy.yml
│ ├── kubeadm-config.yaml
│ ├── kubeadm-config.yaml.tmpl # a.b.c.tmpl will be rendered using envs and rename to a.b.c
│ └── kubelet.service
├── images
│ └── registry.tar # registry docker image, will load this image and run a local registry in cluster
├── Kubefile
├── Metadata
├── README.md
├── registry # will mount this dir to local registry
│ └── docker
│ └── registry
├── scripts
│ ├── clean.sh
│ ├── docker.sh
│ ├── init-kube.sh
│ ├── init-registry.sh
│ ├── init.sh
│ └── kubelet-pre-start.sh
└── statics # yaml files, sealer will render values in those files
└── audit-policy.yml
├── plugins # plugins can run on some hooks, such as pre-init-host, post-install, see more in the plugins documentation
│ └── disk_init_shell_plugin.yaml
├── scripts # scripts can use all ClusterFile's env as Linux env variables
│ ├── init-kube.sh # initialize kube* binaries on target hosts
Copy link
Collaborator

@starnop starnop Jan 5, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please add more information to the scripts, including input, output, and functions should be included?

It can be described in a separate section.

│ ├── clean-kube.sh # remove kube* binaries from target hosts
│ ├── init-container-runtime.sh # initialize container runtime binaries on target hosts
│ ├── clean-container-runtime.sh # remove container runtime binaries on target hosts
│ └── init-registry.sh # initialize registry on local registry's deploy-hosts
└── applications # applications put here
│ ├── redis
│ └── mysql
```

Using cloud rootfs to build a base cloudImage:
Expand All @@ -64,15 +48,6 @@ COPY . .
sealer build -t kuberntes:v1.18.3 .
```

## Metadata

```shell script
{
"version": "v1.18.3",
"arch": "amd64"
}
```

## Hooks

```shell script
Expand Down