Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

이 콘텐츠는 선택한 언어로 제공되지 않습니다.

Chapter 1. How configuration tools work

A YAML file customizes MicroShift instances with your preferences, settings, and parameters.

Note

If you want to make configuration changes or deploy applications through the MicroShift API with tools other than kustomize manifests, you must wait until the greenboot health checks have finished. This ensures that your changes are not lost if greenboot rolls your rpm-ostree system back to an earlier state.

1.1. Default settings
링크 복사

If you do not create a config.yaml file, default values are used. The following example shows the default configuration settings.

  • To see the default values, run the following command: 

    $ microshift show-config
    Copy to Clipboard Toggle word wrap

    Default values example output in YAML form

    dns:
  baseDomain: microshift.example.com
    1 
    
network:
  clusterNetwork:
    - 10.42.0.0/16
    2 
    
  serviceNetwork:
    - 10.43.0.0/16
    3 
    
  serviceNodePortRange: 30000-32767
    4 
    
node:
  hostnameOverride: ""
    5 
    
  nodeIP: ""
    6 
    
apiServer:
  advertiseAddress: 10.44.0.0/32
    7 
    
  subjectAltNames: []
    8 
    
debugging:
  logLevel: "Normal"
    9
    Copy to Clipboard Toggle word wrap

    1
    Base domain of the cluster. All managed DNS records will be subdomains of this base.
    2
    A block of IP addresses from which Pod IP addresses are allocated.
    3
    A block of virtual IP addresses for Kubernetes services.
    4
    The port range allowed for Kubernetes services of type NodePort.
    5
    The name of the node. The default value is the hostname.
    6
    The IP address of the node. The default value is the IP address of the default route.
    7
    A string that specifies the IP address from which the API server is advertised to members of the cluster. The default value is calculated based on the address of the service network.
    8
    Subject Alternative Names for API server certificates.
    9
    Log verbosity. Valid values for this field are Normal, Debug, Trace, or TraceAll.

1.2. Using a YAML configuration file
링크 복사

On start up, MicroShift searches the system-wide /etc/microshift/ directory for a configuration file named config.yaml. To use custom configurations, you must create the configuration file and specify any settings that are expected to override the defaults before starting MicroShift.

1.2.1. Custom settings
링크 복사

To create custom configurations, you must create a config.yaml file in the /etc/microshift/ directory, and then change any settings that are expected to override the defaults before starting or restarting MicroShift.

Important

Restart MicroShift after changing any configuration settings to have them take effect. The config.yaml file is read only when MicroShift starts.

1.2.2. Configuring the advertise address network flag
링크 복사

The apiserver.advertiseAddress flag specifies the IP address on which to advertise the API server to members of the cluster. This address must be reachable by the cluster. You can set a custom IP address here, but you must also add the IP address to a host interface. Customizing this parameter preempts MicroShift from adding a default IP address to the br-ex network interface.

Important

If you customize the advertiseAddress IP address, make sure it is reachable by the cluster when MicroShift starts by adding the IP address to a host interface.

If unset, the default value is set to the next immediate subnet after the service network. For example, when the service network is 10.43.0.0/16, the advertiseAddress is set to 10.44.0.0/32.

1.2.3. Extending the port range for NodePort services
링크 복사

The serviceNodePortRange setting extends the port range available to NodePort services. This option is useful when specific standard ports under the 30000-32767 range need to be exposed. For example, if your device needs to expose the 1883/tcp MQ Telemetry Transport (MQTT) port on the network because client devices cannot use a different port.

Important

NodePorts can overlap with system ports, causing a malfunction of the system or MicroShift.

Consider the following when configuring the NodePort service ranges:

  • Do not create any NodePort service without an explicit nodePort selection. When an explicit nodePort is not specified, the port is assigned randomly by the kube-apiserver and cannot be predicted.
  • Do not create any NodePort service for any system service port, MicroShift port, or other services you expose on your device HostNetwork.

  • Table one specifies ports to avoid when extending the port range:

    Expand
    Table 1.1. Ports to avoid.
    PortDescription

    22/tcp

    SSH port

    80/tcp

    OpenShift Router HTTP endpoint

    443/tcp

    OpenShift Router HTTPS endpoint

    1936/tcp

    Metrics service for the openshift-router, not exposed today

    2379/tcp

    etcd port

    2380/tcp

    etcd port

    6443

    kubernetes API

    8445/tcp

    openshift-route-controller-manager

    9537/tcp

    cri-o metrics

    10250/tcp

    kubelet

    10248/tcp

    kubelet healthz port

    10259/tcp

    kube scheduler

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat