There are some parameters you can't change once a pod is created. containerPort is one of them.

You can add a new container to a pod though. And open a new port.

The parameters you CAN change, you can do it either by dynamically creating or modifying the original deployment (say with sed) and running kubectl replace -f FILE command, or through kubectl edit DEPLOYMENT command; which automatically applies the changes.

This sounds like a perfect use case for Helm (www.helm.sh).

Helm Charts helps you define, install, and upgrade Kubernetes applications. You can use a pre-defined chart (like Nginx, etc) or create your own chart.

Charts are structured like:

mychart/
  Chart.yaml
  values.yaml
  charts/
  templates/
  ...

In the templates folder, you can include your ReplicationController files (and any others). In the values.yaml file you can specify any variables you wish to share amongst the templates (like port numbers, file paths, etc).

The values file can be as simple or complex as you require. An example of a values file:

myTestService:
  containerPort: 33044
  image: "logstash"

You can then reference these values in your template file using:

apiVersion: v1
kind: ReplicationController
metadata:
name: test
namespace: test
spec:
replicas: 1
selector:
app: test
template:
metadata:
  labels:
    app: test
spec:
  containers:
  - name: test
    image: logstash
    ports:
    - containerPort: {{ .Values.myTestService.containerPort }}
    env:
    - name: INPUT_PORT
      value: "5044"

Once finished you can compile into Helm chart using helm package mychart. To deploy to your Kubernetes cluster you can use helm install mychart-VERSION.tgz. That will then deploy your chart to the cluster. The version number is set within the Chart.yaml file.

You can use Kubernetes ConfigMaps for this. ConfigMaps are introduced to include external configuration files such as property files.

First create a ConfigMap artifact out of your property like follows:

kubectl create configmap my-config --from-file=db.properties

Then in your Deployment yaml you can provide it as a volume binding or environment variables

Volume binding :

apiVersion: v1
kind: ReplicationController
metadata:
  name: test
  labels:
    app: test
spec:
  containers:
  - name: test
    image: test
    ports:
    - containerPort: 33044
    volumeMounts:
    - name: config-volume
      mountPath: /etc/creds <mount path> 
  volumes:
    - name: config-volume
      configMap:
        name: my-config

Here under mountPath you need to provide the location of your container where your property file should resides. And underconfigMap name you should define the name of your configMap you created.

Environment variables way :

apiVersion: v1
kind: ReplicationController
metadata:
  name: test
  labels:
    app: test
spec:
  containers:
  - name: test
    image: test
    ports:
    - containerPort: 33044
    env:
    - name: DB_PROPERTIES
      valueFrom:
        configMapKeyRef:
          name: my-config
          items:
          - key: <propert name>
            path: <path/to/property>

Here under the configMapKeyRef section under name you should define your config map name you created. e.g. my-config. Under the items you should define the key(s) of your property file and path to each of the key, Kubernetes will automatically resolve the value of the property internally.

You can find more about ConfigMap here. https://kubernetes-v1-4.github.io/docs/user-guide/configmap/