So, you have 3 problems in one here. This is partial answer unfortunately.

1) @Dinesh is absolutely right with an image.

   containers:
      - name: nginx-container
      - image: nginx

With your config it tries to use 2 images - nginx-container and nginx. Instead of this you want only nginx with name: nginx-container

correct is

spec:
  containers:
  - name: nginx-container
    image: nginx

2) You should always set name: in metadata - this is required field. Without specifying .metadata.name you will get resource name may not be empty

Object: &{map["apiVersion":"v1" "kind":"Pod" "metadata":map["annotations":map["kubectl.kubernetes.io/last-applied-configuration":""] "labels":map["app":"myapp"] "namespace":"default"] "spec":map["containers":[map["image":"nginx" "name":"nginx-container"]]]]}
from server for: "pod-defination.yml": resource name may not be empty

As per Understanding Kubernetes Objects

In the .yaml file for the Kubernetes object you want to create, you’ll need to set values for the following fields:

• apiVersion - Which version of the Kubernetes API you’re using to create this object
• kind - What kind of object you want to create
• metadata - Data that helps uniquely identify the object, including a name string, UID, and optional namespace
• spec - What state you desire for the object

Also as per metadata API Conventions

Every object kind MUST have the following metadata in a nested object field called "metadata":

• namespace: a namespace is a DNS compatible label that objects are subdivided into. The default namespace is 'default'. See the namespace docs for more.
• name: a string that uniquely identifies this object within the current namespace (see the identifiers docs). This value is used in the path when retrieving an individual object.
• uid: a unique in time and space value (typically an RFC 4122 generated identifier, see the identifiers docs) used to distinguish between objects with the same name that have been deleted and recreated

3)pod does not have "kubernetes.io/config.mirror" annotation

pods "blabla" is forbidden: pod does not have "kubernetes.io/config.mirror" annotation, node "blablabla" can only create mirror pods

Above error is typical for situations when you have an issue with [NodeRestriction admission plugin]{https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#noderestriction}

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. […] Admission controllers may be “validating”, “mutating”, or both. Mutating controllers may modify the objects they admit; validating controllers may not. […] If any of the controllers in either phase reject the request, the entire request is rejected immediately and an error is returned to the end-user.

NodeRestriction admission controller:

This admission controller limits the Node and Pod objects a kubelet can modify. In order to be limited by this admission controller, kubelets must use credentials in the system:nodes group, with a username in the form system:node:. Such kubelets will only be allowed to modify their own Node API object, and only modify Pod API objects that are bound to their node. In Kubernetes 1.11+, kubelets are not allowed to update or remove taints from their Node API object.

As per EKS kubernetes platform versions we can see that NodeRestriction is part of Enabled Admission Controllers.

​NamespaceLifecycle, LimitRanger, ServiceAccount, DefaultStorageClass, ResourceQuota, DefaultTolerationSeconds, NodeRestriction, MutatingAdmissionWebhook, ValidatingAdmissionWebhook, PodSecurityPolicy

3 month ago there was already same question but it left without any replies.

As EKS in managed by AWS control plane - seems it is not possible modify built-in admission controllers, but you can look into the Dynamic Admission Controllers and Admission Webhooks. More info can be found in Dynamic Admission Control.

As per Amazon EKS Enables Support for Kubernetes Dynamic Admission Controllers - EKS supports dynamic admission controllers, allowing customers to deploy custom webhooks that enable additional open source tools for controlling network traffic and monitoring Kubernetes clusters on AWS.

I would recommend you use kops to manually create cluster with all the option you need.

Hope it helps

Please try below as image element is not an array

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
  - name: nginx-container
    image: nginx