First, depending on the way you have installed your master nodes, they usually have a taint node-role.kubernetes.io/master:NoSchedule to avoid scheduling of pods.

$ kubectl describe nodes node1
Name:               node1
Roles:              master
Labels:             beta.kubernetes.io/arch=amd64
                    beta.kubernetes.io/os=linux
                    kubernetes.io/hostname=node1
                    node-role.kubernetes.io/master=
Annotations:        node.alpha.kubernetes.io/ttl=0
                    volumes.kubernetes.io/controller-managed-attach-detach=true
Taints:             node-role.kubernetes.io/master:NoSchedule

So if your kubernetes install is conform, there is no need to use a nodeSelector to set the node where the pods are going to be scheduled (it is usually a bad practice).

First solution is to taint your master node for no scheduling if not done during install:

kubectl taint nodes node1 node-role.kubernetes.io/master:NoSchedule-

Second solution: set label to nodes to use nodeSelector

kubectl label nodes node1 gitlab-runner=true

And use nodeSelector to indicate to scheduler you want node with a specific label:

spec:
  containers:
  - [...]
  nodeSelector:
    gitlab-runner: "true"

As mentionned by @Nicolas-pepinster, you can set the label in the [runners.kubernetes] section of our gitlab-runner (see doc).