Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 1. About the default MicroShift configuration file

The MicroShift built-in default settings are listed in a YAML file.

1.1. Configuring Red Hat Device Edge
Copia collegamento

MicroShift and Red Hat Enterprise Linux (RHEL) work together to bring a lighter-weight, single-node Kubernetes to the edge. This combination means that there is a single node that is both control-plane and worker. It also means that the operating system handles many functions. You add features by installing optional RPMs or Operators. In many cases, you must configure the operating system or other resources in addition to the MicroShift service.

Bringing many of these pieces together is the MicroShift configuration file, config.yaml. The MicroShift configuration file customizes your application platform and can enable many advanced functions. For example:

  • Ingress is available by default, but you can add advanced functions such as TLS and route admission specifications by using parameters in the MicroShift configuration file.
  • If you do not need storage, you can disable the built-in storage provider by using the MicroShift configuration file. If you do want to use the built-in storage provider, you must make your adjustments in the lvmd.config file. The role of the MicroShift configuration file in this case is to set whether you use the default storage provider.
  • Advanced networking functions, such as using multiple networks. The Multus package is an installable RPM, but you set up access by using the MicroShift configuration file to set parameters. In addition, you must configure network settings on your networks through the host. For your convenience, a config.yaml.default file is automatically installed. You can copy and rename this file config.yaml and use it as a starting point for your own custom configuration.
Note

You can also add features that operate without configurations to the MicroShift config.yaml file. For example, you can install and configure GitOps for application management without configuring MicroShift.

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.2. The MicroShift configuration file
Copia collegamento

At startup, MicroShift checks the system-wide /etc/microshift/ directory for a configuration file named config.yaml. If the configuration file does not exist in the directory, built-in default values are used to start the service.

You must use the MicroShift configuration file in combination with host and, sometimes, application and service settings. Ensure that you configure each function in tandem when you adjust settings for your MicroShift cluster.

For your convenience, a config.yaml.default file ready for your inputs is automatically installed.

1.2.1. Default settings
Copia collegamento

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

    apiServer:
  advertiseAddress: 10.44.0.0/32
    1 
    
  auditLog:
    maxFileAge: 0
    2 
    
    maxFileSize: 200
    3 
    
    maxFiles: 10
    4 
    
    profile: Default
    5 
    
  namedCertificates:
    - certPath: ""
      keyPath: ""
      names:
        - ""
  subjectAltNames: []
    6 
    
debugging:
  logLevel: "Normal"
    7 
    
dns:
  baseDomain: microshift.example.com
    8 
    
etcd:
  memoryLimitMB: 0
    9 
    
ingress:
  listenAddress:
    - ""
    10 
    
  ports:
    11 
    
    http: 80
    https: 443
  routeAdmissionPolicy:
    namespaceOwnership: InterNamespaceAllowed
    12 
    
  status: Managed
    13 
    
manifests:
    14 
    
  kustomizePaths:
    - /usr/lib/microshift/manifests
    - /usr/lib/microshift/manifests.d/*
    - /etc/microshift/manifests
    - /etc/microshift/manifests.d/*
network:
  clusterNetwork:
    - 10.42.0.0/16
    15 
    
  serviceNetwork:
    - 10.43.0.0/16
    16 
    
  serviceNodePortRange: 30000-32767
    17 
    
node:
  hostnameOverride: ""
    18 
    
  nodeIP: ""
    19
    Copy to Clipboard Toggle word wrap

    1
    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.
    2
    How long log files are kept before automatic deletion. The default value of 0 in the maxFileAge parameter means a log file is never deleted based on age. This value can be configured.
    3
    By default, when the audit.log file reaches the maxFileSize limit, the audit.log file is rotated and MicroShift begins writing to a new audit.log file. This value can be configured.
    4
    The total number of log files kept. By default, MicroShift retains 10 log files. The oldest is deleted when an excess file is created. This value can be configured.
    5
    Logs only metadata for read and write requests; does not log request bodies except for OAuth access token requests. If you do not specify this field, the Default profile is used.
    6
    Subject Alternative Names for API server certificates.
    7
    Log verbosity. Valid values for this field are Normal, Debug, Trace, or TraceAll.
    8
    By default, etcd uses as much memory as needed to handle the load on the system. However, in memory constrained systems, it might be preferred or necessary to limit the amount of memory etcd can to use at a given time.
    9
    Base domain of the cluster. All managed DNS records are subdomains of this base.
    10
    The ingress.listenAddress value defaults to the entire network of the host. The valid configurable value is a list that can be either a single IP address or NIC name or multiple IP addresses and NIC names.
    11
    Default ports shown. Configurable. Valid values for both port entries are a single, unique port in the 1-65535 range. The values of the ports.http and ports.https fields cannot be the same.
    12
    Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Valid values are Strict and InterNamespaceAllowed. Specifying Strict prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized MicroShift config.yaml, the InterNamespaceAllowed value is automatically set.
    13
    Default router status, can be Managed or Removed.
    14
    The locations on the file system to scan for kustomization files to use to load manifests. Set to a list of paths to scan only those paths. Set to an empty list to disable loading manifests. The entries in the list can be glob patterns to match multiple subdirectories.
    15
    A block of IP addresses from which pod IP addresses are allocated. This field is immutable after installation.
    16
    A block of virtual IP addresses for Kubernetes services. IP address pool for services. A single entry is supported. This field is immutable after installation.
    17
    The port range allowed for Kubernetes services of type NodePort. If not specified, the default range of 30000-32767 is used. Services without a NodePort specified are automatically allocated one from this range. This parameter can be updated after the cluster is installed.
    18
    The name of the node. The default value is the hostname. If non-empty, this string is used to identify the node instead of the hostname. You cannot change this immutable setting after MicroShift starts for the first time.
    19
    The IP address of the node. The default value is the IP address of the default route.
Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat