Update readme to remove references to refKey and refName fields

Author: gbraxton

README.md

@@ -95,7 +95,7 @@ spec:
       app: myapp
 ```
 
-The first envConfig is a 'Value' type. An empty type field implies a 'Value' type envConfig. This definition would apply a simple key and value field to the target deployment's container environment variables. The second envConfig is a 'Secret' type. Notice that this envConfig has a value and a refName field. The refName field indicates the name of the secret that this envConfig should be stored in. If the secret does not exist, the kconfig-controller will create it and store the contents of the value field in it. After such an action takes place, the Kconfig is automatically updated with the secretKeyRef to the secret and with the value field removed. The same is true with a 'ConfigMap' type. Notice the final two envConfigs that show how the envConfig appears after a Kconfig is created/updated with a ConfigMap or Secret type envConfig that contains a value. Whenever a get Kconfig is performed, you will never see a value field, as the action is performed immediately on update and the field is automatically removed.
+The first envConfig is a 'Value' type. An empty type field implies a 'Value' type envConfig. This definition would apply a simple key and value field to the target pod's container environment variables. The second envConfig is a 'Secret' type. The Kconfig is automatically updated with the secretKeyRef to the secret and with the value field removed. The same is true with a 'ConfigMap' type. Notice the final two envConfigs that show how the envConfig appears after a Kconfig is created/updated with a ConfigMap or Secret type envConfig that contains a value. Whenever a get Kconfig is performed, you will never see a value field, as the action is performed immediately on update and the field is automatically removed.
 
 ## Build and Push