配置文件
配置文件选项和命令行接口（CLI）标志存在差异，这在很多工具中是常见的现象，下面为你详细分析这种差异并给出一些应对建议：
配置文件 style/usage/structure, e.g
差异分析
命名和结构差异
如--api-port在配置文件里被拆分成kubeAPI字段，且有host、hostIP和hostPort三个子字段。这表明CLI用一个标志表示单一概念，而配置文件里为了更细致地配置，将其拆分成多个子项。
k3d选项被封装在options.k3d作用域中，像--no-rollback被定义为options.k3d.disableRollback。这种封装有助于在配置文件里组织和管理相关选项。
重复标志的表示差异
可重复的标志（如--port）在YAML配置文件里用列表表示。这是因为在CLI中，你可能多次使用同一个标志添加多个值，而在YAML里用列表能更清晰地表达多个值。
使用方法
使用配置文件非常简单，只需将其放在文件系统中一个众所周知的位置，然后通过标志引用它即可：
使用配置文件中的所有选项：k3d cluster create --config /home/me/my-awesome-config.yaml（文件必须为 .yaml 或 .yml 格式）
使用CLI覆盖（集群名称）：k3d cluster create somename --config /home/me/my-awesome-config.yaml
使用CLI覆盖（额外卷）：k3d cluster create --config /home/me/my-awesome-config.yaml --volume '/some/path:/some:path@server:0'
必需字段
在撰写本文档时，配置文件仅要求你定义两个字段：
apiVersion：用于匹配你想使用的配置文件版本（目前应为 apiVersion: k3d.io/v1alpha5）。
kind：用于定义你想使用的配置文件类型（目前我们仅有 “简单配置” 这一种类型）。
因此，下面是一个什么都未配置的最小化配置文件示例：
apiVersion: k3d.io/v1alpha5
kind: Simple配置选项
k3d 的配置选项在不断发展，配置文件（语法）本身也是如此。目前，配置文件仍处于 Alpha 阶段，这意味着它随时可能发生变化（尽管我们会尽量减少重大变更）。
通过 JSON 模式进行验证
k3d 使用 JSON 模式来描述配置文件的预期格式和字段。该模式也用于验证用户提供的配置文件。这个 JSON 模式可以在仓库中特定的配置版本子目录中找到（例如，v1alpha5 版本的可在此处找到），你可以用它来查找支持的字段，或者让代码检查工具（如代码编辑器中的工具）使用它来验证配置文件。所有选项：示例
由于配置选项和配置文件变化相当大，很难跟踪所有受支持的配置文件设置。因此，下面给出一个在撰写本文档时涵盖所有选项的示例：
# k3d configuration file, saved as e.g. /home/me/myk3dcluster.yaml
apiVersion: k3d.io/v1alpha5 # this will change in the future as we make everything more stable
kind: Simple # internally, we also have a Cluster config, which is not yet available externally
metadata:
name: mycluster # name that you want to give to your cluster (will still be prefixed with `k3d-`)
servers: 1 # same as `--servers 1`
agents: 2 # same as `--agents 2`
kubeAPI: # same as `--api-port myhost.my.domain:6445` (where the name would resolve to 127.0.0.1)
host: "myhost.my.domain" # important for the `server` setting in the kubeconfig
hostIP: "127.0.0.1" # where the Kubernetes API will be listening on
hostPort: "6445" # where the Kubernetes API listening port will be mapped to on your host system
image: rancher/k3s:v1.20.4-k3s1 # same as `--image rancher/k3s:v1.20.4-k3s1`
network: my-custom-net # same as `--network my-custom-net`
subnet: "172.28.0.0/16" # same as `--subnet 172.28.0.0/16`
token: superSecretToken # same as `--token superSecretToken`
volumes: # repeatable flags are represented as YAML lists
- volume: /my/host/path:/path/in/node # same as `--volume '/my/host/path:/path/in/node@server:0;agent:*'`
nodeFilters:
- server:0
- agent:*
ports:
- port: 8080:80 # same as `--port '8080:80@loadbalancer'`
nodeFilters:
- loadbalancer
env:
- envVar: bar=baz # same as `--env 'bar=baz@server:0'`
nodeFilters:
- server:0
files:
- description: 'Source: Embedded, Destination: Magic shortcut path'
source: |
apiVersion: v1
kind: Namespace
metadata:
name: foo
destination: k3s-manifests-custom/foo.yaml # Resolved to /var/lib/rancher/k3s/server/manifests/custom/foo.yaml
- description: 'Source: Relative, Destination: Absolute path, Node: Servers only'
source: ns-baz.yaml
destination: /var/lib/rancher/k3s/server/manifests/baz.yaml
nodeFilters:
- "server:*"
registries: # define how registries should be created or used
create: # creates a default registry to be used with the cluster; same as `--registry-create registry.localhost`
name: registry.localhost
host: "0.0.0.0"
hostPort: "5000"
proxy: # omit this to have a "normal" registry, set this to create a registry proxy (pull-through cache)
remoteURL: https://registry-1.docker.io # mirror the DockerHub registry
username: "" # unauthenticated
password: "" # unauthenticated
volumes:
- /some/path:/var/lib/registry # persist registry data locally
use:
- k3d-myotherregistry:5000 # some other k3d-managed registry; same as `--registry-use 'k3d-myotherregistry:5000'`
config: | # define contents of the `registries.yaml` file (or reference a file); same as `--registry-config /path/to/config.yaml`
mirrors:
"my.company.registry":
endpoint:
- http://my.company.registry:5000
hostAliases: # /etc/hosts style entries to be injected into /etc/hosts in the node containers and in the NodeHosts section in CoreDNS
- ip: 1.2.3.4
hostnames:
- my.host.local
- that.other.local
- ip: 1.1.1.1
hostnames:
- cloud.flare.dns
options:
k3d: # k3d runtime settings
wait: true # wait for cluster to be usable before returning; same as `--wait` (default: true)
timeout: "60s" # wait timeout before aborting; same as `--timeout 60s`
disableLoadbalancer: false # same as `--no-lb`
disableImageVolume: false # same as `--no-image-volume`
disableRollback: false # same as `--no-Rollback`
loadbalancer:
configOverrides:
- settings.workerConnections=2048
k3s: # options passed on to K3s itself
extraArgs: # additional arguments passed to the `k3s server|agent` command; same as `--k3s-arg`
- arg: "--tls-san=my.host.domain"
nodeFilters:
- server:*
nodeLabels:
- label: foo=bar # same as `--k3s-node-label 'foo=bar@agent:1'` -> this results in a Kubernetes node label
nodeFilters:
- agent:1
kubeconfig:
updateDefaultKubeconfig: true # add new cluster to your default Kubeconfig; same as `--kubeconfig-update-default` (default: true)
switchCurrentContext: true # also set current-context to the new cluster's context; same as `--kubeconfig-switch-context` (default: true)
runtime: # runtime (docker) specific options
gpuRequest: all # same as `--gpus all`
labels:
- label: bar=baz # same as `--runtime-label 'bar=baz@agent:1'` -> this results in a runtime (docker) container label
nodeFilters:
- agent:1
ulimits:
- name: nofile
soft: 26677
hard: 26677提示
k3d 会在对配置文件进行任何处理之前，无条件地对其中的环境变量（如 $VAR 或 ${VAR}）进行展开。配置文件与 CLI 标志
k3d 分别使用 Cobra 和 Viper
这会自动引入一个 “配置选项优先级顺序”（优先顺序）：
配置优先顺序
信息来源：spf13/viper#why - viper
内部设置 > CLI 标志 > 环境变量 > 配置文件 > （键值存储 >）默认值这意味着，你可以定义一个 “基础配置文件”，其中包含你在不同集群间共享的设置，然后仅通过 CLI 标志 / 参数覆盖这些集群之间存在差异的字段。
例如，你使用同一个配置文件创建三个集群，这些集群仅在名称和 Kubernetes API（--api-port）设置方面有所不同。