OpenShift/Kubernetes配置文件困惑：OpenShift Origin主容器配置问询

Hey there! Let me break this down clearly for you—since I’ve spent plenty of time digging into OpenShift Origin’s config files, I know how confusing this can be at first.

First, Why Duplicate Files Across Containers? #

OpenShift Origin’s core containers (like origin-master, origin-node, or the main control plane containers) often share base images or mount common config volumes from the host. So those duplicate files you’re seeing are either default templates baked into the image, or shared copies of the actual active configs. No need to panic—this is totally normal.

Key Config Files & Their Purposes #

Here’s a breakdown of the most critical files you’ll encounter, and what each does:

• /etc/origin/master/master-config.yaml: The heart of your control plane (master nodes). This holds all settings for the API server, controller manager, and scheduler—think auth policies, API endpoints, etcd connection details, cluster networking rules, and more. Any change to how your cluster’s control plane runs starts here.
• /etc/origin/node/node-config.yaml: The core config for worker nodes. It controls the kubelet, container runtime (Docker/CRI-O), node network plugin (like OpenShift SDN), resource limits for pods, and image pull policies. Each worker node has its own version of this file.
• /etc/origin/master/htpasswd: If you’re using htpasswd for user authentication, this stores encrypted username/password pairs—your go-to file for managing basic cluster users.
• /etc/origin/master/ca.crt / server.crt / server.key: Cluster CA and API server TLS certificates/keys. These ensure secure communication between all cluster components; every service trusts the CA cert here.
• /var/lib/origin/openshift.local.config/master/admin.kubeconfig: The admin-level kubeconfig file. Use this with oc or kubectl to run cluster-wide admin operations (like creating projects, modifying roles).
• /etc/origin/node/resolv.conf: DNS config for the node—pods inherit this to resolve cluster service names and external domains.

Do You Need to Target All Config Files for Commands? #

Absolutely not—you only need to point to the specific file that’s actively used by the component you’re working with. Here’s how to figure it out:

1. Control plane operations: When modifying master components (e.g., restarting the API server, updating auth settings), target /etc/origin/master/master-config.yaml. This is the actual file the master processes load—other copies in containers are either defaults or read-only replicas.
2. Worker node operations: For node-specific changes (e.g., adjusting kubelet resources), modify the node-config.yaml on the target worker node. Each node uses its own local config file.
3. oc/kubectl commands: By default, these use ~/.kube/config in your user home. To run admin commands, specify the admin kubeconfig with oc --config=/var/lib/origin/openshift.local.config/master/admin.kubeconfig login—no need to touch other kubeconfig copies.
4. Container-internal checks: If you’re inside a container, run ps aux to see the component’s startup command. For example, the master API server will have --config=/etc/origin/master/master-config.yaml in its args—this tells you exactly which file it’s using.

Pro Tip #

Always verify if a config file in a container is a host-mounted volume (use df <file-path> to check) or an image-internal file. Only host-mounted files will affect the cluster when modified—image-internal files are just defaults.

内容的提问来源于stack exchange，提问作者Franco Rondini