data and not just Git. So going forward, you can use the same approach of retrieving configuration data from external systems and storing it into a volume, but rather than using the predefined  gitRepo  volume, use the more flexible  Init Container  method. We explain this technique in detail in “Kubernetes Init Containers” on page 159. ConfigMaps and Secrets allow the storage of configuration information in dedicated resource objects that are easy to manage with the Kubernetes API. The most signifi‐ cant advantage of using ConfigMaps and Secrets is that they decouple the  definition of configuration data from its  usage . This decoupling allows us to manage the objects by using configurations independently from the configurations. Another benefit of ConfigMaps and Secrets is that they are intrinsic features of the platform. No custom construct like that in Chapter 20,  Immutable Configuration  is required. However, these  Configuration Resources  also have their restrictions: with a 1 MB size limt for Secrets, they can’t store arbitrarily large data and are not well suited for non‐ configuration application data. You can also store binary data in Secrets, but since they have to be Base64 encoded, you can use only around 700 kb data for it. Real-world Kubernetes clusters also put an individual quota on the number of Con‐ figMaps that can be used per namespace or project, so ConfigMap is not a golden hammer. The next two chapters show how to deal with large configuration data by using Immutable Configuration  and  Configuration Templates . More Information Discussion • Configuration Resource Example • ConfigMap Documentation • Secrets Documentation • Encrypting Secret Data at Rest • Distribute Credentials Securely Using Secrets • gitRepo Volumes • Size Restriction of a ConfigMap 156  |  Chapter 19: Configuration Resource