You're actually mixing two entirely-separate concepts here. (It's okay... the names are confusingly similar!)
"The kernel" lives in the highest-heavens of the computer. It creates
the environment in which all user-level processes run. It knows about all processes, and all threads within those processes, and "it gives them life." But in so doing, it does not ... actually cannot
... play by their rules. It does not have access, itself, to the programming facilities that it affords to the user-land threads and processes which run under its benevolent tutelage.
Well ... somewhere along the way, some kernel-programmer thought that this was rather an unfair limitation. It occurred to this person that many of the essential tasks that the kernel performs can
most-easily be thought of in terms of "threads," which are
dispatched much like ordinary user-land threads but which run entirely in kernel-space. Such threads are, in other words, "entirely part of the kernel ... entirely divine..." but
they are also "threads" and therefore capable of doing the things that threads can do. Things like "waiting," and "doing I/O," and so-on.
Typical example? How about "the virtual-memory swapper?" When you set about to describe how it works and what it does, you might find yourself saying that it ... waits for
the amount of available memory to drop, then scans through (and locks...
) virtual memory segments and performs I/O
to move them out to disk ... and signals
other threads, and ... you get the idea. All of these things, are things that threads
can quite-naturally do.
But what if "'the kernel' can't do what threads do?"
The obvious answer is: "figure out a way for 'the kernel' to be able to support 'threads!'" So... somebody did.
A "kernel thread," then, is a thing which the kernel actually can
"dispatch," under most (but not all) of the usual rules and conditions that apply to "threads," but which is nevertheless a fully-privileged part of "the kernel." It is an asynchronous
"part of the kernel."
Ponder that for a while . . .