make-kpkg is a command from the package kernel-package, which used to be part of the official packaging infrastructure for the kernel packages that get shipped in the Debian distribution. It is not being used for that purpose anymore because the current maintainer for the kernel packages inside the Debian distribution chose to stop using it; however, the authors of the kernel-package package have not stopped maintaining it, so it is still an officially supported way of creating your own Debian packaged version of a kernel. It has various options and targets; the most important ones are the ones you refer to in your question, i.e., kernel-image (which builds a package containing the kernel and modules that you selected during make config), and kernel-headers (which contains the include files that you might need if you want to compile an out-of-tree module). The kernel-package package is maintained as part of the Debian (or derivative, like Ubuntu) release with which it was released, so as a result if things change in the Debian infrastructure then newer versions of kernel-package will be updated to incorporate it, and they will ship with that version of Debian. As a result, a kernel package created by the kernel-package package is always tailored best for the version of Debian on which it was created. However, if things change within the Linux kernel in a way that makes kernel-package break, then updating your kernel package for a stable version of Debian may be somewhat complicated.
make deb-pkg is a target in the Linux kernel's build infrastructure. It receives patches from Debian developers, but as it is not maintained within Debian itself, it always uses the tools and policies that are most up to date at the point in time where the kernel version you're trying to build was created. This means that in some cases, it might try to use a tool that isn't available on an older distribution yet. As it is not maintained inside Debian, it is not an officially-supported method (at least not from the point of view of Debian) for creating kernel packages; having said that though, it is mostly maintained by people who are involved in Debian, and so there is no reason to suspect that it won't work.
Whichever method you choose is just a matter of preference; unless you are heavily invested in peculiar outcomes of the package building options, both methods will work just fine.
Best Answer
Debian (and Ubuntu and other derivatives) divides Linux kernel packages into several parts:
linux-image-VERSION-PATCHLEVEL-FLAVORcontains the kernel image that is loaded by the bootloader, a file containing the symbol table (used by some system tools), a file containing the kernel configuration (informative for the system administrator), and modules that can be loaded dynamically. This is the package that is needed for normal use of the system.linux-headers-VERSION-PATCHLEVEL-FLAVORcontains headers that are shipped with the kernel source or generated during the kernel compilation. These headers are needed to compile third-party kernel modules.linux-libc-devcontains headers that are used to compile userspace programs. These headers are backwards compatible (unlike the headers used to compile kernel modules), so there is no need to install multiple versions.linux-doc-VERSIONcontains kernel documentation. It is useful for people who write kernel modules or diagnose kernel-behavior.linux-source-VERSIONcontains the kernel sources. People who want to compile their own kernel can install this binary package and unpack the archive that it contains.linux-tools-VERSIONcontains tools that depend on the kernel version. Currently there is onlyperf.The packaging distinguishes VERSION (the upstream version) from PATCHLEVEL (incremented on each change that affects binary compatibility). A bug fix can affect binary compatibility, so modules need to be recompiled, so it must be possible to install multiple patchlevels of kernels (and headers and third-party modules), so that you can have both the files for the running kernel and the files for the kernel that you'll next reboot to installed at the same time. There's a single package per version for the documentation and the source because there's no need to have multiple copies of them for different patchlevels.
The different FLAVORs correspond to kernel compilation options. Some kernel options are compromises, for example to support computers with large physical memory (at the expense of an overhead in kernel memory) or only computers with small physical memory (less overhead but a smaller maximum amount of RAM).
In current versions of Ubuntu, there are only two kernel flavors: “generic” (suitable for most computers) and “lowlatency” (which makes programs more reactive at the cost of a little more CPU overhead, see https://askubuntu.com/questions/126664/why-to-choose-low-latency-kernel-over-generic-or-realtime-ones). Debian has many more, most of which only make sense on specific architectures.
In addition to the packages with full version numbers, there are metapackages with no version as part of the package name. That way, you can install e.g.
linux-image-genericwhich always depends on the latestlinux-image-VERSION-PATCHLEVEL-genericpackage. For example,linux-image-genericversion 3.13.0.42 depends onlinux-image-3.13.0-42-generic,linux-image-genericversion 3.13.0.43 depends onlinux-image-3.13.0-43-generic, etc. As thelinux-image-genericpackage gets upgraded, newer kernel packages are pulled in.